C平台（H / W + S / W）是依赖还是独立

Question

如果使用所有平台通用的所有标准C库编写C程序，无论是Unix（任何风格）还是Windows（即stdio.h，math.h等），并使用标准编译器（即GCC）并在任何一个相同的CPU arch上运行它，为什么二进制文件不会在符合所有上述标准的不同机器上运行？

当我在X86 Mac上编译C程序时，只使用标准库，为什么不能在Linux或Windows下在相同的CPU架构上运行该编译的二进制文件？

是否因为在C运行时期间发生了特定于平台的库链接或者是什么？

Answer 1

可执行二进制文件不仅仅是所需源代码和库的机器语言的组合，而是跳过现在的答案仍然是否定的：您链接的库特定于它们将要运行的系统继续前进。例如，你质疑mac vs linux ...每个系统都有自己的方式来调用陷阱进入系统（例如I / O），如果你的可执行文件有链接到它的那些项目（而不是通过共享）对象），你从一开始就注定要失败。

回到“特定于系统”...不仅像系统调用这样的问题，而且有多个可执行的二进制格式，这将导致你在很多时候不仅仅是轻微的痛苦。例如，OS X使用“Mach-O”二进制格式，而Linux使用“ELF”格式。当然，在这些文件中，您可以找到相同可执行文件的相似代码，但是您会发现该数据的不同二进制布局使得在一个系统上看起来是直接的，而另一个系统上完全未知。许多示例中的一个...... Mach-O格式在可执行文件中嵌入了其动态加载的库所在的位置 - 例如，相对于加载可执行文件的绝对位置或位置。这个概念（据我所知）不是ELF或Windows“PE”格式。

Answer 2

忽略问题第10行以下的文本墙，以及二进制文件与操作系统无关的一些基本原因：

• 每个操作系统都有一个可执行加载程序，可以执行某些操作，例如加载依赖库，设置堆栈指针等...
• 即使CPU架构是相同的，OS架构也不是，并且一些C库函数是内联实现的，导致特定OS的实现被编译到您的可执行文件中。
• 函数调用的工作方式可能不同（例如Windows vs Linux）。

所有这些实际上都是由操作系统定义的ABI（应用程序二进制接口）的一部分（如果操作系统实现由于例如专利问题而无法实现，则有时是编译器。）

我能想到的最后一个原因：

• C运行时不同;标准留下了很多东西实现定义，这意味着许多C库在这些方面有所不同。从理论上讲，可以为所有操作系统架构实现可移植的libc，但由于操作系统界面中隐藏的细节（在Windows或Mac的情况下）或结构差异（Linux与BSD），这通常是不可能的，这最终导致不同的实施方式。

Answer 3

另请阅读此Is C++ platform dependent?

1. 它回答了你的问题
2. 它告诉你如何提出问题