在一个Linux发行版上使用g ++编译的可执行文件是否受到限制？

Question

在一个发行版上直接使用另一个发行版上会影响用GCC 4.7.x编译的C ++二进制文件的发行版之间是否有任何特性或变化？我理解理想的情况是在第二个发行版上从源代码编译，但我真的不想担心在我的生产机器上编译新的GCC版本和程序源代码。我是一个相对缺乏经验的linux用户（因此问题！）并且仍然更喜欢IDE而不是命令行编译，ssh是我真正可以用来访问生产机器的。

代码本身并不是什么有趣的东西，但它确实利用了一些工厂OS设施，如阻塞套接字等。

非常感谢任何建议！

Answer 1

除非二进制文件构建在完全相同的操作系统（包括版本）和完全相同的硬件上，否则无法保证。

在实践中：

1. 如果硬件是同一系列的芯片，它应该可以工作。

   • 这是因为大多数人都没有打开硬件特定的优化（但他们可以）。
   • 在芯片组中移动二进制文件的可能性很小
   • 将二进制文件从较旧的硬件系列成员移动到较新的成员可能会起作用
   • 将二进制文件从硬件系列的较新成员移动到旧成员的可能性较小（但取决于优化和编译器设置（从64位架构到32位架构不太可能有效）。

2. 如果操作系统具有相同的主号码，则应该（可能）有效。

   • 二进制文件可以使用的操作系统版本取决于用于构建它的编译器的版本和主机操作系统。
   • 如果编译器在其生成的ABI中发生了更改，则所有投注均已关闭。但通常编译器生成的ABI的变化将是一个主要问题，因此只发生在操作系统路线图中的主要点（而不是小幅增加）。

3. 我的建议来自源。

   • 不要专门出去更新开发环境（使用分发附带的开发环境（如果你进行默认更新，它们不会破坏向后兼容性）。）
   • 构建很简单，只需阅读README文件即可。但通常它涉及运行两个命令./configure和make。如果你不想要任何特别的东西，你通常不需要做任何其他事情。

Answer 2

G ++已经有一段稳定的ABI了，所以不应该引起问题。可能导致问题的是使用动态链接库。运行程序的系统需要具有可编译可执行文件的任何共享库的兼容版本。如果仅使用静态链接，则应该没有问题。您可以使用-static选项打开静态链接。

Answer 3

使用静态链接时，必须满足两个条件：

1）目标系统和构建系统必须具有相同的体系结构（例外情况：您可以在许多64位主机上运行32位二进制文​​件）

2）目标系统上的（g）libc软件包不能是比构建系统更旧的版本（有时可以避免出现较小的版本差异）

动态链接变得更加复杂。

Answer 4

通常，基于较新版本构建的二进制文件不适用于旧版本，但在较旧版本上构建的二进制文件将更新版本。 目前，如果你在RedHat EL4上构建二进制文件，它将适用于大多数支持的发行版。（如果缺少，你可能需要复制libstdc ++）