什么时候交叉编译一个编译器有意义？

Question

我刚刚经历了一个“等等，嗯……”的时刻。

假设您要为目标架构 a 生成编译器 A，通常配置阶段的结果取决于您用于 --target= 的值，这意味着您的工具需要能够为 a 生成和处理编译对象。

现在，通常在以 gcc 作为主要编译器的通用 GNU/Linux 发行版下，您想要的第一件事是获取 binutils 并为您的目标构建它们，但您没有与您的目标兼容的编译器给定目标，因为这是您首先要尝试做的，为 a 创建工具链，所以这里开始了难题：如何打破这个循环？

现在假设我之前的示例考虑并运行在具有架构 b 的机器上，与 a 明显不同，因为我们一直在谈论交叉编译如果你很幸运，硬件制造商在 a 架构的机器上发布了 gcc for a，你仍然需要解决如何构建 a 在 b 上并中断前一个循环。换句话说，即使您在原始架构上获得了对编译器的支持，当您想要交叉编译时，它也不会发挥任何作用。

那么这背后的逻辑是什么以及如何打破循环？

Answer 1

“gcc”编译器也是“self-hosting”。因此，您通常在非目标平台上构建“stage1”编译器，然后移动到目标系统并使用“stage1”重新构建编译器（运行通过“stage3”）。

您首先需要了解“Target Triplets”（您列出了一个“--target”），但您也有“--host”和“--build”。从链接，

--build=构建类型

配置和编译软件包的系统类型。它默认为运行 config.guess 的结果。

--host=主机类型

运行包的系统类型。默认情况下，它与构建机器相同。指定它启用交叉编译模式。

--target=目标类型

软件包中的任何编译器工具为其生成代码的系统类型（很少需要）。默认情况下，它与主机相同。

另请参阅Cross Linux From Scratch 和NetBSD 的惊人作品。