是否可以在较新的 gcc 上制作目标代码 (*.o)，以及 然后在另一台机器上链接它们(连同像 libc 这样的标准库)。 如果机器相同，它应该可以工作，但我对两个版本不同的情况感兴趣。这假设机器的基本架构(但不一定是所有东西)就像两个系统都是 linux，它们具有不同的风格或不同的内核版本 (不能混用 mac、linux 和 windows)。众所周知，各种 Linux 发行版的标准存储库具有不同的标准库
我的一个非常简单的例子奏效了，但我想知道这在一般情况下是否可行，以及通常的陷阱是什么？
它与Dev production libc/libstdc++ mismatch [link libc.so.6/libstdc++.so.6 with older version]有关但觉得这足够具体，可以单独提出一个问题
最佳答案
您拥有的唯一保证是 ABI 向前兼容性。这意味着旧的编译二进制文件仍应针对较新版本的标准库运行(glib 和 libstdc++ 都尽最大努力使这项工作成功)。
您的建议是组合针对不同库和不同编译器构建的那些二进制文件的构建 block 。由于多种原因，这可能会惨败:
- 假定其参数采用某种双二进制布局的内联函数被传递给相同类型的较新版本。
- 一个函数修改了一些内部库全局状态(线程本地存储、errno 等)，但针对新库构建的目标文件以不同方式进行修改，或者全局已更改/删除。
- 编译器/库 ABI 略有不同。这可能是由多种原因造成的，包括优化选项。
在最好的情况下，由于符号不匹配，您会遇到链接器错误，但我不会指望它能防止更糟的情况发生。
请注意，至少在 Linux 上，静态库只是一组目标文件，因此上述所有内容也适用于它们。
不要在这个层面上混搭，就是不要。为自己和其他人省去麻烦!
关于linux - 跨不同机器编译(使用不同的 gcc)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38922370/