为什么编译器通常只为安装在其上的平台生成可执行文件？

Question

我是一名C++开发人员，为了更好地理解跨平台开发，我试图更好地了解编译器的一些实现细节，以及它们是如何创建特定于操作系统的二进制文件的。在我的研究中，我意识到，至少在一段时间内，您为特定平台下载的大多数编译器只编译了该平台的二进制文件。因此，如果您下载了用于Windows的编译器exe附带的IDE，那么该编译器只能为x86-x64 windows应用程序编译程序，而不能编译Linux或Mac应用程序。

现在我理解了不同的平台需要不同的二进制格式，但是为什么windows上的可视化C++编译器很难生成一个linux二进制可执行文件呢？只要您有您正在运行的CPU的组装指令，以及操作系统特定的库，难道您就不能为任何机器上的任何平台编译可执行程序吗？

Answer 1

是什么使windows上的可视化C++编译器难以生成linux二进制可执行文件？

除了微软不愿意这么做之外，什么都没有。这些障碍不是技术性的。

开发工具链只是接受输入并产生输出的程序。Visual C++生成x86程序集，然后使用汇编程序将其转换为x86对象文件。如果微软想让它生成ELF，它只是代码:程序集进来，ELF退出。对象文件或库没有什么神奇之处；它们只是一种很好理解的格式的数据块。

早在石器时代，交叉编译就困难得多，因为通常情况下，您会为目标平台编写工具链，并为其运行的平台进行组装。这意味着，如果世界上只有VAX、M68K和Alpha体系结构，那么整套交叉编译器将需要编写其中的九个，其中大部分是从头开始编写的。(VAX-to-VAX，VAX-to-M68K，VAX-to-Alpha，M68K-to-VAX，M68K-to-M68K，等等)这有点夸张，因为可以重用VAX编译器的部分，并将其附加到每个目标的代码生成器中(例如，VAX、M68K和Alpha，每个都是为VAX编写的)。

当我们开始用一种与特定处理器无关的语言编写编译器时，这个问题就消失了。这样的C就意味着你只需用C编写整个工具链，然后使用编写本地平台C编译器来构建它。(在本地平台的编译器上引导编译器之后，您通常会使用编译器重新编译自己，但这是另一个讨论。)这样做的结果是，构建交叉编译器与在本地平台上构建本机编译器的工作本质上是一样的。唯一重要的区别是，在构建过程的某个地方，您告诉它在目标平台的代码生成器中编译，而不是本地平台的代码生成器，这是合理的选择。GCC通过构建每个本地/目标平台对构建了一个二进制文件(而且现在仍然这样做)。

随着编译器体系结构的发展，简单地包含和构建所有的代码生成器和产品，并选择在运行时使用的代码生成器变得非常方便。Clang/LLVM就是这样做的，我相信还有其他的。

一旦您有了一个工作工具链(编译器、汇编程序、链接器)，库就会从源代码中构建出来，最终您将得到为其他平台生成可执行文件所需的一切。

Answer 2

是的，如果你有你的目标平台的所有信息，那么你实际运行的平台就不重要了。

有两个问题往往会出现：

1. 人们不关注这个问题，因为这是一个不太常见的情况。通常，交叉编译的唯一方法是编译器，这样就可以停止交叉编译了。注意力减少就意味着更糟的支持。
2. 重要的程序需要的不仅仅是代码。当您已经有了运行平台的库时，处理库包含/链接就会变得容易一些。他们将在一个著名的位置，在一个众所周知的编码。

当然，这些并不是不可逾越的。大多数情况下，您会得到针对他们运行的平台的编译器，因为这正是人们所想要的。

Answer 3

我不同意你的假设。目前有数以百万计的安卓和iOS开发者。它们都使用运行在Windows或Mac上的编译器，为一台完全不同的计算机生成代码。

如果没有市场需求，就不会有交叉编译器。例如，为Linux桌面开发代码的人大多可以使用Linux桌面，并且将使用基于Linux的编译器--如果您可以在编译的机器上直接运行应用程序而不通过网络传输应用程序，那么在同一台计算机上运行调试器会更容易、更快，等等。

那么，如果微软的编译器也为Linux构建，微软还能赚多少钱呢？大约0美元。还要为Windows创建更多的软件？没有。还将创建多少Linux软件？不知道，但这不是微软关心的事情。费用是多少？相当可观。编译器必须没有bug。他们必须接受测试。

另一个问题:如果您在Windows上编写编译器，您需要知道如何编写Windows软件的人。如果您为Linux编写编译器，您需要一个知道如何编写Linux软件的人。如果您为运行在Windows上的Linux编写了一个编译器，那么您突然需要熟悉Windows和Linux的开发人员的更少的面包了。