静态链接是否允许跨平台执行？

如何解决静态链接是否允许跨平台执行？

我很好奇静态链接的 C 可执行文件如何在不同的环境中工作。假设我们编译我们的 C 代码以针对 x86 MacO，并且我们静态地包含它在可执行文件中使用的所有内容（print、strlen）。如果我们包含它需要的每个库，什​​么真正阻止这个可执行文件在 Windows 操作系统中运行？我知道文件格式可能不同并且会中断，但除此之外，这在技术上是否能够运行？

解决方法

我知道你从哪里来，操作系统让我们作为程序员认为库是编程的最终目的，调用库是使复杂的事情发生所需要的一切，并且一切包含在其中。

但事实是，图书馆大多提供 abstraction layer。例如，让我们创建一个名为“hello_world.so”的库，它会打印“Hello World！”到控制台。我们创建的那个库依赖于 stdio 来处理复杂的 I/O 内容，但 stdio 本身至少依赖于另一件事：内核（某些特定目标在没有内核的情况下工作，但这些系统超出了本答案的范围）。>

在桌面世界中，事情会变得非常复杂，即使在空闲系统中，我们也有数百个进程同时运行，所有这些应用程序都需要访问硬件（可能也是同时），因此决定使用控制器需要一些软件来协调在同一台计算机上运行的所有其他软件。这块软件通常称为内核。在 Windows 上是 NT 内核，在 macOS 上是 XNU，在 Linux 上是……Linux 内核！

在这些系统上，库的最大工作是抽象内核，让我们相信在 Linux 或 Windows 控制台上打印文本的工作方式完全相同，而实际上它可以完全不同的！像 stdio/time/etc 这样的库有不同的“实现”，但有相同的“接口”：从开发的角度来看，它们看起来是一样的，但它们实现目标的方式可能大不相同，它们可以进行转换，调用其他隐藏的或非隐藏功能...所有这些都可以从一个操作系统完全移植到另一个操作系统，但是当内核调用开始出现时，事情开始向南走。

内核调用是程序与内核“对话”的方式。它们可以用来做成千上万种不同的事情，但例如有一个（或几个）请求内存（通常用 malloc 调用），一个打印到控制台，一个询问网络数据包是否到达，要求与您的 GPU 通话...这些系统调用在一个内核与另一个内核之间完全不同，有时甚至对于同一内核的两个版本！

这些“内核调用”是阻止您在 Windows 上运行静态编译的 linux 程序的唯一原因。

PS：尽管以上所有内容都是完全正确的，内核可以随心所欲地彼此不同，但由于内核和一般计算的历史，一些内核实际上共享相同的接口（即使它们的实现正如您所猜测的，可能完全不同）。我所知道的最好的例子是我所知道的大多数内核都是基于 UNIX 内核的。

这意味着 - 尽管我自己从未测试过 - 我认为您应该能够静态链接 Linux 应用程序并在 Linux、大多数 BSD 甚至 macOS 上使用它

,

二进制文件和库特定于操作系统。

,

TLDR 是链接过程将函数调用转换为指向操作系统特定库的地址。有一些差异，例如在编译时发生的对齐，但负责 x86 指令不在不同操作系统下运行的是链接器。

您的编译器生成可以执行但不完整的 x86 指令。链接器将进入每个函数调用，在可执行文件中给出该函数的地址，即使是标准库的函数也是如此。

链接器将按照文件格式创建可执行文件，该文件格式具有包含大小、元数据和入口点等信息的标头。Windows 和 Unix 对可执行文件有不同的规范。 Windows 具有 PE 和 Unix 具有 ELF 格式的可执行文件和库。

通过一些技巧和重要的技巧，可以创建一个可以在 Windows 和 Unix (see αcτµαlly pδrταblε εxεcµταblε for how) 上运行的可执行文件。

但即使你做了这一切，也有一个无法绕过的障碍：内核。内核是一个内核。这是最重要的事情 一个操作系统，它提供一组 API 调用，提供对计算机资源的基本和低级访问，因此 malloc 等功能是使用内核特定的 API 调用实现的，VirtualAlloc 用于 Windows 和 vmalloc 或 { {1}} 用于 POSIX。

,

主要答案

如果你的程序做了任何有用的事情（打印输出、返回值、在网络上通信），它包含某种形式的系统调用指令。每个系统调用指令都是对特定操作系统的请求，macOS 系统调用不适用于 Windows，反之亦然。

系统调用指令向操作系统发送信息，包括标识请求哪个服务的编号。执行该服务的操作系统。当您为 macOS 构建程序时，它包括包含系统调用指令的库例程。如果您在 Microsoft Windows 系统上执行这些指令，Windows 将无法理解 macOS 请求。它将以不同的方式解释信息，并且程序将无法运行。

因此，理论上，没有什么可以阻止您编写自己的程序加载器，该程序加载器读取用于 macOS 的 ELF 可执行文件，将其内容加载到内存中，并将控制转移到其入口点。但是由于系统调用，程序将无法运行。

补充

您可以考虑翻译程序中的所有系统调用。更改标识服务请求的主要号码可能是可行的；它可能不需要过多地更改可执行文件。例如，如果 37 是 macOS 上的“写入文件”请求，则您的程序加载器可能会在 Windows 上将其更改为 48。但是，系统调用还需要传递其他数据，例如指向缓冲区的指针、长度等，并且这些数据的传递方式可能存在许多差异，因此无法轻松将 macOS 请求转换为 Windows 请求。此外，识别程序中使用某条指令的所有位置在技术上也具有挑战性——加载程序的内存内容有些是指令，有些是数据。大多数正常程序在这方面可能表现良好且易于分析，但并非所有程序都如此。

另一个潜在问题是程序可能希望在处理器中设置某些模式，而主机操作系统可能会或可能不会根据需要设置这些模式。