我只是有一个“等什么，嗯......”时刻。
假设您要为目标体系结构 a 生成编译器 A ，通常配置阶段的结果取决于您用于{{1}的值}，意味着您的工具需要能够生成和处理 a 的编译对象。
现在，通常在使用gcc作为主编译器的常见GNU / Linux发行版下，你想要的第一件事是获取binutils并为你的目标构建它们，但是你没有与你的兼容的编译器给定目标，因为这是你首先要做的，为 a 创建一个工具链，所以这里开始了一个难题：如何打破这个循环？
现在假设我之前的示例考虑并在具有 b 架构的机器上运行，明显不同于 a ，因为我们总是在谈论交叉编译例如，你很幸运，硬件制造商在具有 a 架构的机器上发布 a 的gcc，你仍然必须解决如何构建 a <的问题/ strong> on b 并打破上一个循环。换句话说，即使您在原始体系结构上获得对编译器的支持，当您想要交叉编译时，这也不起任何作用。
那么这背后的逻辑是什么以及如何打破循环？
答案 0 :(得分：2)
“gcc”编译器也是“self-hosting”。因此，您通常在非目标平台上构建一个“stage1”编译器，然后移动到目标系统并使用“stage1”（运行“stage3”）重新构建编译器。
首先需要了解“Target Triplets”（你列出了一个“--target”），但你也有“--host”和“--build”。从链接
- 构建=积聚型
正在配置和编译包的系统类型。它默认为运行config.guess的结果。
- 主机=主机型
程序包运行的系统类型。默认情况下，它与构建计算机相同。指定它可启用交叉编译模式。
- 目标=目标型
包中的任何编译器工具生成代码（很少需要）的系统类型。默认情况下，它与主机相同。
另请参阅Cross Linux From Scratch，以及NetBSD处的惊人的工作。