根据gcc ABI 策略,gcc 4.4.7 应该依赖于libstdc++ 6.0.13。据我所知,编译器版本和 libstdc++ 版本是密切相关的,不能互换,所以我惊讶地发现以下事实:
- CentOS 5.8 以某种方式设法拥有一个链接到 6.0.8 的 gcc44 软件包,显然是默认系统(基于 gcc-4.1.2)附带的
- 编译器目录(/usr/lib/gcc/x86_64-redhat-linux6E/4.4.7,我希望在其中找到 libstdc++-6.0.13)中的 libstdc++.so 不是指向共享对象的链接任何类型的,但包含
INPUT ( -lstdc++_nonshared/usr/lib64/libstdc++.so.6 )
的文本文件
这里发生了什么样的魔法?
具体来说:
- 他们如何提供链接到旧版本 libstdc++ 的 gcc 4.4.7?我认为这是不可能的。
- 这个 stdc++_nonshared 库是什么?
- 我不知道 .so 文件可以包含该文本。谁解析它(我猜是动态链接器)以及它的规范和结果是什么?
- 这个魔法能走多远?我可以将 gcc4.7 与 libstdc++ 6.0.3 一起使用吗?兼容性的范围是什么
最佳答案
What kind of magic is going on here?
这主要是 ELF 符号版本控制的魔力。我见过的最好的引用是 How to Write Shared Libraries作者 Ulrich Drepper,特别是第 3 节。
How could they provide a gcc 4.4.7 that links against an older version of libstdc++? I thought it was not possible.
libstdc++ 开发人员非常注意 ABI 兼容性。这使得查看两个不同版本的 libstdc++ 之间引入的新符号变得相当简单。
查看 libstdc++ 的 ABI compatibility page ,你可以看到 GCC 4.1 的 libstdc++ 有 GLIBCXX_3.4.8,而 GCC 4.4 的库存(FSF 版本)有 GLIBCXX_3.4.13。然后可以查看 libstdc++ version scripts查看这两个版本之间添加了哪些符号。
查看符号版本的更靠经验的方法是使用像 readelf 这样的工具。例如。在我的 Ubuntu 系统上 readelf --dyn-syms --wide/usr/lib/x86_64-linux-gnu/libstdc++.so.6 | c++filt
显示这样的输出(只是几个选定的短行):
223: 000000000006dbe0 2121 FUNC GLOBAL DEFAULT 12 std::ios_base::Init::Init()@@GLIBCXX_3.4
...
226: 00000000002ed920 1 OBJECT GLOBAL DEFAULT 27 std::adopt_lock@@GLIBCXX_3.4.11
注意符号名称末尾的符号版本,在 @@
之后。
what is this stdc++_nonshared library?
结合上一段中的点,stdc++_nonshared 是一个静态库,它包含将在 libstdc++.so.6.0.13 中但不在 libstdc++.so.6.0.8 中的符号。
I didn't know a .so file could contain that text. Who parses it (dynamic linker I guess) and what are its specifications and consequences?
常规链接器解析它,而不是运行时链接器。请参阅 INPUT in a linker script 的 binutils 文档.因此,链接到这个特殊的 libstdc++.so.6.0.13 将导致链接器动态链接到 libstdc++.so.6.0.8,并静态链接到包含额外符号的库。
这样做的缺点是,以这种方式编译的应用程序会比动态链接到仅包含所有必要符号的库存 libstdc++.so.6.0.13 的同一应用程序更加臃肿。好处是来自较新标准库的功能可以用于旧系统的标准安装,而无需独立软件供应商提供他们自己的 libstdc++ 拷贝。
How far can this magic go? Can I use gcc4.7 with libstdc++ 6.0.3? What is the spectrum of compatibility
既然您已经知道它的魔力是什么,您可能会意识到您拥有的这个 GCC 4.4 版本是专为 Centos 5(好吧,最初是 Red Hat 5)制作的特殊版本。因此,您可能可以创建一个 GCC 4.7,它将生成只需要 libstdc++ 6.0.3 的二进制文件,但它需要大量的工作来修补您的 GCC 树以将正确的符号放入 stdc++_nonshared.a。您至少可以查看 gcc44 RPM 的源代码,了解 Red Hat 是如何做到的。
Red Hat 似乎在他们的 Red Hat Developer Toolset 中延续了这种方法。 .在撰写本文时,GCC 4.8.1 是最新的编译器,它可以为 EL5 构建二进制文件,而 EL5 仍然只需要在目标系统上安装 libstdc++.so.6.0.8。这对于想要使用 C++11 编写但需要能够在 EL5 或 EL6 上部署的开发人员来说非常有用。
关于c++ - 带有 gcc 4.4.7 的 CentOS 5.8 链接到 libstdc++ 6.0.8。这怎么可能?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16880830/