C 通过将静态bulid转换为特定于操作系统的二进制文件来跨操作系统构建

有没有可能用C编写代码，然后静态地构建它，并像ELF/PE一样从中生成一个二进制文件，然后删除它的头文件和所有不必要的元数据，从而创建一个原始二进制文件，并最终能够将该原始二进制文件放入任何其他类型的操作系统中，如（ELF>PE）或（PE>ELF）？！ 你以前做过这个吗？ 可能吗？ 什么是问题和关切？ 这怎么可能？！ 如果没有，就告诉我为什么没有

在理解静态构建时，我的陷阱是什么？ 这难道不意味着它消除了对第三方和标准以及os LIB和头文件的任何需求吗？！ 为什么我们不能删除例如ELF的meta和put meta以及PE所需的其他规范

提及： 我说，跨操作系统而不是跨硬件

[阅读下面的内容后再阅读！]

---

正如您看到的最佳答案，到目前为止（！）请继续学习跨平台开发问题！！！这有多疯狂？！感谢哲学

我想说这是可能的，但这个过程肯定会被很多很多细节所阻碍

ABI兼容性 首先要考虑的是应用程序二进制接口的兼容性。除非您能够以相同的方式调用函数，否则代码将被破坏。因此，我猜想（尽管我目前无法检查）在Linux/OS X上使用gcc编译代码和在Windows上使用MinGW gcc编译代码应该提供相同的二进制代码，只要不调用外部函数即可。这里的问题是，可执行元数据可能依赖于某些ABI假设

标准库 这似乎是最大的障碍。部分原因是C预处理器可以在某些平台上内联某些过程，让它们在其他平台上运行。此外，与标准库的跨平台动态互操作几乎是不可能的，尽管理论上可以想象一个代码使用C标准库的有限子集，该子集通过不同平台上的相同ABI公开

静态构建基本上消除了与其他用户空间代码交互的问题，但与内核接口仍然存在一个巨大的问题：x86 Linux上的

int$0x80

调用和一组平台特定的系统调用号，它们不会以任何直接方式映射到Windows

操作系统特定寄存器使用 据我所知，Windows使用register%fs来存储一些操作系统范围的异常处理内容，因此在Linux上编译的二进制文件应该避免将其弄乱。可能还有其他类似的问题。此外，Windows上的C++异常主要是用OS异常完成的。 虚拟地址 同样，AFAIK Windows DLL有一些预定义的地址，它们必须加载到进程的虚拟地址空间中，而Linux使用位置无关的代码来共享库。因此，可能存在可执行代码和移植代码重叠区域的问题，除非将移植的位置相关代码重新编译为位置独立的代码

因此，虽然理论上是可能的，但这种转换在实际情况下必须非常脆弱，并且不可能重新植入整个静态构建代码——某些部分可能会完整地传输，但必须重新链接到与其他内核接口的系统特定代码

---

另外，我认为这是一个在完全不同的系统上运行二进制代码的好例子。它欺骗Windows程序，使其认为自己在Windows环境中运行，并使用相同的机器代码—大多数情况下运行良好（如果程序不使用私有系统低级例程或不可用的库）

当我们在理论上，一切看起来都是可能的！但是，当您在现有系统和平台的保护下工作时，您会发现标准很重要！此外，我认为还必须考虑一些更普遍的问题，例如所需的编译时间、结果二进制文件的大小以及更多！这其实不值得去做！