谁在使用 g++ 构建二进制文件时确定 GLIBCXX_version?

Who determine GLIBCXX_version when build a binary using g++?

我正在 Centos 6.8.

上使用 G++ 4.9.3 构建一个自制的共享库

这个库使用 boost::interprocess::file_lock 并且 boost 的版本是 1.41.0.

我没有在多个环境中工作。我只是使用一个设备,并且在构建库后我从未更改过构建环境。

当我构建库时,g++ 构建得很好。但是当我 运行 它通过与二进制文件链接时,它显示 "./a.out: /usr/lib64/libstdc++.so.6: 找不到版本 `GLIBCXX_3.4.15'(./libmylib.so 要求)" .

所以,我检查了 libstdc++ 支持哪些版本,它显示它不支持高于 3.4.13 的 GLIBCXX。 GLIBCXX_3.4.13是最新版本/usr/lib64/libstdc++.so.6支持.

即使我在设备上工作并且它的 libstdc++ 不支持 GLIBCXX_3.4.15,从我的设备构建的库需要 GLIBCXX_3.4.15.

即使我使用相同的编译器 (g++4.9.3),另一个二进制文件也不需要 GLIBCXX_3.4.15。他们只是工作得很好。

图书馆如何注意到它应该使用 GLIBCXX_3.4.15?

源代码不同吗?

编译器是否告诉库如"you require to use GLIBCXX_3.4.15 because you use some special grammar in your code"?

我想知道谁来决定将哪个版本的 GLIBCXX 用于二进制文件。

这取决于 GCC 的版本、编译器标志和源代码。 GLIBCXX_3.4.15 等符号仅在程序中使用特定功能时才被引用。此特定符号版本的功能列表相当大。您可以使用此命令了解哪些功能是相关的(您必须 运行 针对 较新的 libstdc++,即 GCC 4.9 附带的那个):

$ readelf -sW libstdc++.so.6 | awk '/@GLIBCXX_3.4.15/{print }' \
  | sort -u \
  | c++filt

如果您想 运行 使用 Red Hat Enterprise Linux 或 CentOS 附带的未修改 libstdc++.so.6 版本的程序,您可以使用 Developer Toolset (which is also available as a supported part of Red Hat Enterprise Linux。 Developer Toolset 通过使用旧的(C++98 时代)C++ ABI 并提供不属于特定目标操作系统版本的系统 libstdc++ 版本的函数的静态链接副本,避免了对较新符号版本的依赖。