c++ - 静态链接 libstdc++ : any gotchas?

Question

我需要将一个基于 Ubuntu 12.10 和 GCC 4.7 的 libstdc++ 构建的 C++ 应用程序部署到运行 Ubuntu 10.04 的系统上，该系统带有相当旧版本的 libstdc++。

目前，我正在使用 -static-libstdc++ -static-libgcc 进行编译，正如这篇博文所建议的那样:Linking libstdc++ statically .作者警告不要在静态编译 libstdc++ 时使用任何动态加载的 C++ 代码，这是我尚未检查的内容。尽管如此，到目前为止一切似乎都很顺利:我可以在 Ubuntu 10.04 上使用 C++11 功能，这正是我所追求的。

我注意到这篇文章是从 2005 年开始的，从那时起可能已经发生了很大变化。它的建议是否仍然有效？有什么我应该注意的潜在问题吗？

Answer 1

那篇博文非常不准确。

As far as I know C++ ABI changes have been introduced with every major release of GCC (i.e. those with different first or second version number components).

不正确。自 GCC 3.4 以来引入的唯一 C++ ABI 更改是向后兼容的，这意味着 C++ ABI 已经稳定了近九年。

To make matters worse, most major Linux distributions use GCC snapshots and/or patch their GCC versions, making it virtually impossible to know exactly what GCC versions you might be dealing with when you distribute binaries.

发行版的 GCC 补丁版本之间的差异很小，并且 ABI 不变，例如Fedora 的 4.6.3 20120306(Red Hat 4.6.3-2)的 ABI 与上游 FSF 4.6.x 版本兼容，几乎可以肯定与任何其他发行版的任何 4.6.x 兼容。

在 GNU/Linux GCC 的运行时库上使用 ELF 符号版本控制，因此很容易检查对象和库所需的符号版本，如果您有一个提供这些符号的 libstdc++.so，它将可以工作，它是否与您的发行版的另一个版本略有不同并不重要。

but no C++ code (or any code using the C++ runtime support) may be linked dynamically if this is to work.

这也不对。

也就是说，静态链接到 libstdc++.a 是您的一种选择。

如果您动态加载库(使用 dlopen)它可能无法工作的原因是，当您(静态)链接它时，您的应用程序可能不需要它所依赖的 libstdc++ 符号，所以这些符号不会出现在您的可执行文件中。这可以通过将共享库动态链接到 libstdc++.so 来解决(如果它依赖于它，这无论如何都是正确的做法。)ELF 符号插入意味着存在于可执行文件中的符号将由共享库使用，但您的可执行文件中不存在的其他内容将在它链接到的任何 libstdc++.so 中找到。如果您的应用程序不使用 dlopen，则无需关心。

另一种选择(也是我更喜欢的选择)是将较新的 libstdc++.so 与您的应用程序一起部署，并确保在默认系统 libstdc++.so 之前找到它，这可以通过强制动态链接器查找正确的位置来完成，或者在运行时使用 $LD_LIBRARY_PATH 环境变量，或者通过在可执行文件中设置 RPATH链接时间。我更喜欢使用 RPATH，因为它不依赖于为应用程序正确设置的环境。如果您使用 '-Wl,-rpath,$ORIGIN' 链接您的应用程序(注意单引号以防止 shell 尝试扩展 $ORIGIN)，那么可执行文件将具有$ORIGIN 的 RPATH 告诉动态链接器在与可执行文件本身相同的目录中查找共享库。如果将较新的 libstdc++.so 放在与可执行文件相同的目录中，它将在运行时找到，问题就解决了。 (另一种选择是将可执行文件放入 /some/path/bin/ 并将较新的 libstdc++.so 放入 /some/path/lib/ 并与 链接'-Wl,-rpath,$ORIGIN/../lib' 或相对于可执行文件的任何其他固定位置，并将 RPATH 设置为相对于 $ORIGIN)