为什么需要针对目标的标准库构建（主机）GCC？答案

【问题标题】：Why does (host) GCC need to be built against the target's standard library?为什么需要针对目标的标准库构建（主机）GCC？
【发布时间】：2021-11-23 00:59:03
【问题描述】：

我一直在研究构建跨工具链，并且对 gcc 的编译和工作有一个普遍的疑问。

问题是关于official gcc documentation的这段摘录：

为了构建 GCC，C 标准库和头文件必须存在于将为其构建目标库的所有目标变体（不仅是宿主 C++ 编译器的变体）。

为什么构建（交叉）编译器本身需要目标的标准库？宿主机上运行的（交叉）编译器不应该只需要构建宿主机的标准库就可以编译目标的标准库吗？

我还在 crosstool-NG 的 how a toolchain is constructed 上找到了这个：

最终的编译器需要 C 库，知道如何使用它，但是：构建 C 库需要编译器

这与上面所说的一致，但我不明白为什么最终编译器需要针对预构建的目标 C 库构建，只是知道如何在以后使用它。对于目标 C 库，主机编译器有什么需要了解的？在编译时将目标程序与目标的标准库链接不是链接器的工作吗？

【问题讨论】：

诚实的答案是：懒惰。 GCC 跨工具链引导程序充满了丑陋的杂物，而且有些地方彻底坏掉了。根据您的问题：实际上曾经有一个 GCC 交叉引导错误，其中 libc 的 automake/configure 阶段会失败，因为 configure 确实使用交叉编译器来构建功能测试程序并尝试在主机架构上运行它（这显然行不通，除非使用 binfmtmisc 和 qemu 的组合来透明地支持外部架构二进制文件）。
我唯一能找到并知道的是gnu/stubs.h，基本上有__stub_FUNCTION，在配置gcc时用于detecting if function exists。

标签： c gcc cross-compiling gnu toolchain

【解决方案1】：

因为这是确保为目标平台创建工作编译器的唯一方法。创建一个不工作的编译器，将它分发到目标平台，然后发现它是没有用的然后是没有意义的。

一般来说，非共享对象的可执行文件只有在没有未解析的符号时才能成功创建。

根据GCC 11.2 "Overall Options" documentation

编译最多可涉及四个阶段：预处理、正确编译、汇编和链接，始终按此顺序进行。 GCC 能够将多个文件预处理和编译成几个汇编程序输入文件，或者编译成一个汇编程序输入文件；然后每个汇编器输入文件生成一个目标文件，链接将所有目标文件（新编译的和指定为输入的）组合成一个可执行文件。

所以最后一步是链接。 GNU linker 'ld' man page 声明：

通常链接器会为每个报告了未解析的符号，但选项 --warn-unresolved-symbols 可以将其更改为警告。

和

--error-unresolved-symbols 这恢复了链接器的默认生成行为报告未解析符号时出错。

因此，默认情况下，当存在未解析的符号时，链接会失败。

为什么？

因为如果存在未解析的符号，则生成的可执行文件在运行时将无法工作。

确保没有未解析符号的唯一方法是在交叉编译时从目标平台获取所有必要的库，以便在链接新的编译器可执行文件时解析所有符号。

【讨论】：

OP 没有询问交叉编译本身的过程，而是询问构建将用于交叉编译的编译器（将在主机平台上运行）的任务本身。而且由于交叉编译器将在主机架构（而不是目标）上运行，因此它显然将链接到主机架构的库，而不是目标架构。
@datenwolf 他说的是新编译的交叉编译器（将为其他目标架构生成二进制文件）。新的交叉编译器在为目标架构生成二进制文件时需要目标架构的 libc 才能正确解析符号。
@Fractal 但是符号解析不是链接器的工作吗？
@Flo 我不知道正确答案，但我猜libc 可能是了解目标平台 ABI 的唯一方法。也就是说libc定义了平台的ABI？
@Fractal 是的，libc 定义了平台的 ABI。但据我了解，libc 只是一组与给定平台接口的函数，其中一些函数由它的头文件公开。并且只要链接器知道在哪里可以找到这些函数，二进制文件在运行时调用它们应该不是问题。即使构建二进制文件的编译器不是针对上述 libc 构建的。