通过将静态bulid转换为os特定的二进制文件来交叉os构建

Question

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

在理解静态构建过程中，我遇到了哪些缺陷？这不意味着它消除了对第三方和标准以及os库和标题的任何需求吗？！为什么我们不能删除的元，例如ELF和放置元和其他规格所需的PE？

提到:我说过，交叉操作系统不是交叉硬件

在下面读完后再读！正如你所看到的最好的答案，直到现在(!)继续学习跨平台开发问题吧！这有多疯狂？！感谢哲学！

Answer 1

我想说这是可能的，但是这个过程必须被许多很多细节所削弱。

ABI兼容性

首先要考虑的是应用程序二进制接口兼容性。除非您能够以同样的方式调用您的函数，否则代码就会中断。因此，我猜想(虽然目前我无法检查)，在没有调用外部函数的情况下，与gcc一起在Linux/OS上编译代码和在MinGW上编译gcc应该提供相同的二进制代码。这里的问题是可执行元数据可能依赖于一些ABI假设。

标准图书馆

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

静态构建基本上消除了与其他用户空间代码交互的问题，但与内核接口仍然存在一个巨大的问题:在x86 Linux上的x86调用和一组不以任何直接方式映射到x86的平台特定的syscall数字。

操作系统专用寄存器的使用

据我所知，Windows使用寄存器%fs来存储一些操作系统范围内的异常处理程序，因此在Linux上编译的二进制文件应该避免混淆它。可能还有其他类似的问题。而且，Windows上的C++异常大多是在操作系统异常情况下完成的。

虚拟地址

同样，AFAIK Windows DLL有一些它们必须加载到进程的虚拟地址空间中的预定义地址，而Linux则使用与位置无关的代码来实现共享库。因此，可能会出现可执行文件和移植代码重叠区域的问题，除非与位置相关的移植代码被重新编译为独立于位置的代码。

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

我认为葡萄酒是在完全不同的系统上运行二进制代码的一个很好的例子。它欺骗一个Windows程序，以为它在Windows环境中运行，并且使用相同的机器代码--大多数情况下运行良好(如果程序不使用私有系统的低级例程或不可用的库)。