您如何找到Linux计算机上安装了哪个版本的libstdc ++库？

我发现以下命令：strings /usr/lib/libstdc++.so.6 | grep GLIBC从这里开始。似乎可行，但这是一种临时/启发式方法。

是否有可用于查询C ++库版本的特定命令？还是我找到了可接受的方法？

要查找正在使用哪个库，可以运行

 $ /sbin/ldconfig -p | grep stdc++
    libstdc++.so.6 (libc6) => /usr/lib/libstdc++.so.6

libstdc ++ 3.4.0及更高版本的兼容版本列表由提供

 $ strings /usr/lib/libstdc++.so.6 | grep LIBCXX
 GLIBCXX_3.4
 GLIBCXX_3.4.1
 GLIBCXX_3.4.2
 ...

对于早期版本，该符号GLIBCPP已定义。

库的日期戳在宏中定义，__GLIBCXX__或__GLIBCPP__取决于版本：

// libdatestamp.cxx
#include <cstdio>

int main(int argc, char* argv[]){
#ifdef __GLIBCPP__
    std::printf("GLIBCPP: %d\n",__GLIBCPP__);
#endif
#ifdef __GLIBCXX__
    std::printf("GLIBCXX: %d\n",__GLIBCXX__);
#endif
   return 0;
}

$ g++ libdatestamp.cxx -o libdatestamp
$ ./libdatestamp
GLIBCXX: 20101208

libstdc ++版本的日期戳表在文档中列出：

您到底想知道什么？

共享库的名称是？这是文件名的一部分libstdc++.so.6，或显示为readelf -d /usr/lib64/libstdc++.so.6 | grep soname。

次要修订号？您只要检查一下符号链接指向的内容，就应该能够得到：

$ ls -l  /usr/lib/libstdc++.so.6
lrwxrwxrwx. 1 root root 19 Mar 23 09:43 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.16

这告诉您是6.0.16，这是该版本的第16个修订libstdc++.so.6版，与GLIBCXX_3.4.16符号版本相对应。

还是您说的是发布版本？它的部分海合会所以它的同一版本的GCC，所以除非你已经通过安装的版本不匹配搞砸了你的系统g++和libstdc++.so你可以得到来自：

$ g++ -dumpversion
4.6.3

或者，在大多数发行版中，您可以只问软件包管理器。在我的Fedora主机上

$ rpm -q libstdc++
libstdc++-4.6.3-2.fc16.x86_64
libstdc++-4.6.3-2.fc16.i686

正如其他答案所说，您可以通过检查ABI文档将发行版本映射到库版本

我倾向于使用的机制是从libstdc ++readelf -V转储.gnu.version信息，然后是与GLIBCXX_提取的最大值匹配的查找表的组合。

readelf -sV /usr/lib/libstdc++.so.6 | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1

如果您的版本sort太旧而无法-V选择（按版本号排序），则可以使用：

tr '.' ' ' | sort -nu -t ' ' -k 1 -k 2 -k 3 -k 4 | tr ' ' '.'

而不是，sort -u -V最多可以按4个版本号进行排序。

通常，匹配ABI版本应该足够好。

但是，如果您要查找libstdc++.so.<VERSION>，可以使用一些bash，例如：

file=/usr/lib/libstdc++.so.6
while [ -h $file ]; do file=$(ls -l $file | sed -n 's/.*-> //p'); done
echo ${file#*.so.}

所以对于我的系统来说就是这样6.0.10。

但是，如果您尝试获取在systemX上编译以在systemY上运行的二进制文件，那么到目前为止，这些事情只会使您步入正轨。在这些情况下，请携带用于该应用程序的libstdc ++。so副本，然后拥有一个执行脚本，该脚本执行以下操作：

export LD_LIBRARY_PATH=<directory of stashed libstdc++.so>
exec application.bin "$@"

通常可以解决.so的问题，该问题与应用程序的版本不兼容。对于更极端的环境差异，我倾向于只添加所有依赖库，直到应用程序正常运行为止。这相当于在Linux上解决dll被视为dll hell的问题。

您可以g++ --version结合使用GCC ABI文档来查找。