C++ 将GCC与新的glibc和binutils结合使用，为具有较旧sysroot的系统构建软件

几个月以来我一直有一个问题，很长一段时间我都无法用谷歌来回答

背景： 我正在为运行linux发行版ptxdist的基于arm的控制器交叉编译软件。完整的linux映像是使用交叉gcc（4.5.2）构建的，该gcc是针对glibc-2.13和binutils-2.21构建的。 C++标准相当旧，所以我建立了一个新的工具链，支持C++ 11（GCC 4.85）。它现在是根据glibc-2.20和binutils-2.24构建的。我想在控制器上为我的应用软件使用新的编译器（不是完整的映像，只是这一个“主”二进制文件），它通过包管理系统更新

---

软件似乎正在运行。我只需要将LD_LIBRARY_PATH设置为指向libstdc++.so.0.19，而不是二进制文件的libstdc++.so.14。但它不接受新的libc，即libc-2.20而不是libc-2.13

因此二进制文件使用libstdc++.So.0.19，系统的其余部分不变

问题: 为什么会这样？ 运行此软件可能会有什么风险？我应该这样做吗？ 例如，二进制文件将来是否会因为只在目标机器上获得glibc-2.13而错过glibc-2.20的某些功能？不可能根据glibc-2.13构建gcc-4.8.5

到目前为止，我已经了解到这取决于ABI内部的变化：

这里说，如果由GCC4.1构建到GCC4.8，那么C代码是兼容的

---

谢谢大家!

glibc2.14引入了

memcpy@GLIBC_2.14

symbol，因此几乎所有针对glibc 2.20编译的软件都无法在glibc 2.13上运行，因为该符号在那里缺失。理想情况下，您应该根据glibc2.13而不是glibc2.20构建新的GCC。您声称针对Glibc2.13构建GCC4.8.5是不可能的，但这显然不是事实

<> P>一些较新的C++特性将与旧的系统LBSTDC++一起工作，因为它们只依赖于模板（来自头文件），而在LBSTDC++.<

---

您还可以研究混合链接模型如何在Red Hat Developer工具集中工作。它以静态方式链接libstdc++的较新部分，同时依赖libstdc++系统来处理常见的较旧部分。通过这种方式，您可以获得异常等方面的适当互操作性，并且不必在目标系统上安装更新的libstdc++。

这方面的好材料可以是：

我的最终解决方案是：

我构建了GCC4.8.5作为交叉编译器。我无法使用较旧的glibc2.13构建它，只能使用版本2.20。这也许是可能的，但在我的情况下，它不起作用。无论如何，这不是问题，因为我还使用sysroot标志构建了它。编译新软件完全依赖于我的旧系统，包括C运行时。我没有得到一个新的C++标准，但是如果你打开编译器优化，我体验到更好的二进制压缩和性能。 关于一个新的C++标准，我可以用我的交叉编译器链接一个新的LIbSTDC++ +，使用-L:BBSTDC++.SO.60.19作为LDDFLAG。因此，我只需要在旧的libstdc++之外的目标上复制一个额外的libstdc++。 在使用

strings libstdc++.so.6.0.19 | grep GLIBC 

您可以观察到，它不依赖于任何比GLIBC_2.4更新的符号。看来我永远不会遇到丢失符号的问题。

---

因此，在我的例子中，我很幸运地使用了新的C++11标准，而没有对系统的其余部分进行任何更改。如果有新的符号被引入，你需要在我的文章中遵循上面的链接，这些链接信息丰富。但我永远不会为自己尝试。在我的例子中，对于GCC4.9.4，libstdc++.so.6.0.20得到了指向GLIBC_2.17的符号。这可能会给我带来麻烦，因为我正在使用GLIBC_2.13进行交叉编译。

它将一直工作，直到某些东西需要比GLIBC-2.13提供的符号更新的符号为止。我测试了一些“更新的”C++11功能，如std:：thread，这是旧编译器无法理解的，并且运行良好。我不知道如何用新符号强调二进制……”“它不接受新的libc”你怎么知道的？无论如何，gcc是如何构建的并不重要。重要的是如何编译二进制文件。