是否有任何特质或发行版之间的变化会影响与GCC 4.7.x汇编的C 二进制文件，这是一个直接在另一个发行版上使用的发行版？我知道理想的情况是从第二个发行版中的来源编译，但我真的不必担心编制新的GCC版本和生产机器上的程序源代码。我是一个相对缺乏经验的Linux用户（因此！），仍然更喜欢IDE，而不是命令行编译，SSH是我真正可以用来访问生产机器的全部。
代码本身并不有趣，但是它确实使用了一些磨机设施，例如阻止插座等。
任何建议将不胜感激！
，除非二进制文件是基于恰好构建的，相同的OS（包括版本）和恰好 没有保证的硬件。<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<</p>
实践：
-
如果硬件是相同的芯片家族，则应起作用。
- 这是因为大多数人不会打开特定于硬件的优化（但可以）。
- 跨芯片套件移动二进制文件极不可能起作用
- 将二进制文件从较旧的二进制学转移到硬件家族的较新成员
- 将二进制文件从较新的硬件家族的老年成员移动到较小的可能性（但会取决于优化和编译器设置（IR从64位移动到32位体系结构不太可能起作用）。
-
如果操作系统具有相同的主要编号，则应该（可能）工作。
- 二进制将使用的OS版本将取决于用于构建它的编译器的版本和主机OS。
- 如果编译器在生成的ABI中具有更改，则所有赌注都关闭。但是通常，编译器生成的ABI的变化将是一个主要问题，因此仅在OS路线图的主要点发生（不是以较小的增量）。
-
我的建议从来源构建。
- 不要专门出去更新开发环境（使用带有分销的环境（如果执行默认更新，它们不会向后兼容））。
- 建筑物很容易，只需阅读
README文件即可。但通常涉及运行两个命令./configure和make。如果您不想要任何特别的东西，通常不需要做其他事情。
g 已经有一个稳定的ABI一段时间了，因此不应该引起问题。可能引起问题的是使用动态链接的库。运行该程序的系统将需要具有对可执行文件反对的任何共享库的兼容版本。如果您仅使用静态链接，则不应该有问题。您可以使用-static选项打开静态链接。
具有静态链接，必须满足两个条件：
1）目标系统和构建系统必须具有相同的体系结构（例外：您可以在许多64位主机上运行32位二进制文件）
2）目标系统上的（g）libc软件包不得比构建系统上的版本较旧（有时您可以摆脱较小的版本差异）
动态链接变得更加复杂。
一般而言，建立在较新的分布上的二进制文件对较旧版本不起作用，但是构建基于较旧的分布的二进制文件将起到更新的作用。目前，如果您在Redhat EL4上构建二进制文件，它将在支持的大多数分布中使用。（您可能需要复制libstdc （如果丢失））