跨不同机器编译（使用不同的 gcc）答案

【问题标题】：Compiling across different machines (with different gcc)跨不同机器编译（使用不同的 gcc）
【发布时间】：2016-08-12 16:12:38
【问题描述】：

是否可以在较新的 gcc 上制作目标代码 (*.o)，以及然后将它们（以及像 libc 这样的标准库）链接到另一台机器上。如果机器相同，它应该可以工作，但我对两个版本不同的情况感兴趣。这假设机器的基本架构（但不一定是所有东西）就像两个系统都是 linux，它们具有不同的风格或不同的内核版本（没有混合mac、linux和windows）。众所周知，各种 Linux 发行版的标准存储库具有不同的标准库

我的一个非常简单的例子有效，但我想知道这是否可能，以及常见的陷阱是什么？

它与Dev production libc/libstdc++ mismatch [link libc.so.6/libstdc++.so.6 with older version] 相关，但认为这足够具体，值得单独提出一个问题

【问题讨论】：

标签： linux gcc cross-compiling

【解决方案1】：

您拥有的唯一保证是 ABI 前向兼容性。这意味着旧编译的二进制文件仍应针对较新版本的标准库运行（glib 和 libstdc++ 都尽最大努力做到这一点）。

您的建议是将针对不同库和不同编译器构建的这些二进制文件的构建块结合起来。由于多种原因，这可能会失败：

假定其参数具有某种二进制布局的内联函数会传递相同类型的较新版本。
一个函数修改了一些内部库全局状态（线程本地存储、errno 等），但针对新库构建的目标文件的做法不同，或者全局已更改/删除。
编译器/库 ABI 略有不同。这可能是由多种原因造成的，包括优化选项。

在最好的情况下，由于符号不匹配而导致链接器错误，但我不会指望它会阻止更糟的情况。

请注意，至少在 Linux 上，静态库只是一组目标文件，因此上述所有内容也适用于它们。

不要在这个级别上混搭，只是不要。为自己和其他人省去麻烦！

【讨论】：

有趣的信息，尽管在我的情况下编译器版本是相同的（但 libc 和 libstdc++ 以及相关版本更新）。如果您可以查看我的其他问题并提出一些解决方法，那就太好了。在将此标记为答案之前，我很可能会遵循此建议，但要等待更多时间。谢谢
@ssj3892414 由于前向兼容性，您应该始终针对您想要支持的最旧版本的 glibc/libstdc++ 构建。那么一切都应该正常。
@ssj3892414 - 在基于 rpm 的发行版上，您可以通过运行 rpm -q --provides glibc 检查库支持的最高 API 版本。将glibc 替换为适当的库包。我很确定基于aptitude 的发行版有类似的命令。应使用新旧通用的最高 API 版本。为保证这一点，请始终在具有较低版本的系统上编译。