二进制不兼容有几个级别/来源。
首先解决库不兼容问题
通常，如果您在另一台机器上运行二进制文件，使用不同版本的“相同操作系统”（无论这意味着什么......），那么它会运行良好。完全地。问题不在于代码不起作用，而是缺少代码：二进制文件所依赖的操作系统位在目标机器上不存在。找不到要运行的代码，而不是运行代码是失败（这完全可以，直到它尝试使用丢失的位！）
因此，来自 Ubuntu gcc 的二进制文件很可能在任何不比编译它的机器旧的 linux 系统上运行。这完全取决于二进制文件依赖于操作系统和系统库中的哪些功能。
很少有二进制文件没有外部依赖。在您的输出中使用 ldd 检查依赖关系。最有可能导致问题的是 libgcc 依赖项。 libc 和朋友很少更改，因此几乎不会造成兼容性问题。 GCC 经常更改，因此会限制您的二进制文件将在其上运行的目标计算机。
一般规则是：使用您想要运行的最古老的发行版作为构建机器。因此，使用 RHEL 2 构建机器，您将能够在任何不旧的系统上运行二进制文件（有一些例外）。这是一个让事情变得简单的通用准则。如果您需要跨许多发行版的二进制兼容性，静态链接到 libstdc++（如果您使用 C++）是一个很好的选择。静态链接到 libgcc 是危险的，除非您真的知道自己在做什么，否则不要尝试。
最后，请注意库兼容性在其他 UNIX 平台上要简单得多；只有 linux 这么痛苦。在 AIX 6（比如说）或 SunOS 5.8 或 HP-UX 11.00 上编译的任何东西，或者在所有更高版本上运行都没有问题的任何东西。环境足够同质，他们可以在他们的系统库中提供大量遗留的垃圾，以保证旧版本中存在的每个符号都可以在具有相同语义的最新版本中使用。
其次，跨操作系统二进制文件：操作系统之间的运行时差异
这只是机器代码，因此您可能会认为二进制文件应该可以在其他操作系统上运行。他们不会。一个很大的原因是系统调用：当您需要从内核调用某些东西时（这对于大多数重要的功能来说都是必需的），您必须知道如何“与内核对话”。也就是说，您进行系统调用并告诉操作系统，“做 42 件事，你知道的”。
系统调用的数量取决于内核。所以，Solaris 二进制文件在 linux 上是可以的，除了会停止几乎所有工作的小问题。
事实上，一些操作系统确实支持其他内核的系统调用。 FreeBSD 知道 linux 系统调用，当你告诉它“做 42 件事”时，它会检查你的 ELF 标题中的一个标志，如果 ELF 被标记为 linux 系统调用号，它会对 linux 系统调用号执行适当的操作。整洁的。 （当然，你也需要链接 linux 库......但是，静态链接的 linux 二进制文件在 FreeBSD 中运行良好，无需外部。）
第三，加载时跨操作系统兼容性
二进制不是“只是一个二进制”；它包含一整套元数据，这些元数据在内核运行之前会被内核解释。大多数二进制文件是一团代码和数据，以及链接器信息。但是，即使是没有任何外部依赖的东西也必须能够被内核解析。
一些内核可以理解多种二进制格式，例如 PE、ELF 或 a.out（已过时）。 linux 二进制文件永远不会在 Windows 上运行，即使它们没有进行任何系统调用（这样的二进制文件不能干净地退出，但为了举例......）。那是因为 MS 不打算在他们的内核中添加 ELF 支持：Windows 无法读取描述如何加载和启动它的代码的包装器，因此它内部的代码不会运行：Windows 不会'不知道文件的哪些位是偶数！