# 5.2\. 工具链技术说明 本节阐述了整个构建方法的一些基本原理和技术细节，您不必马上就理解本节中的所有内容。在您实际操作之后，就会了解大多数的东西，您可以在任何时候回顾本节。 [第五章](chapter05.html)的总体目标是提供一个临时环境，您可以 chroot 到这个环境，在里面构建一个[第六章](../chapter06/chapter06.html)中的干净、没有问题的目标 LFS 系统。为了尽量的与宿主系统分开，我们创建了一个自包含、自依赖的工具链。要注意的是，这个创建过程被设计为尽量减少新手犯错误的可能，同时尽可能多的提供教育价值。 ### 重要 在继续之前，要先知道工作平台的名称，就是所谓的"target triplet"(目标三元组)，许多时候，target triplet 可能是 _i686-pc-linux-gnu_ 。要确定 target triplet 的名称，有一个简单的方法就是运行许多源码包里都有的 `config.guess` 脚本。解开 Binutils 的源码包，然后运行脚本 **`./config.guess`** 并注意输出的内容。 工作平台的动态连接器名称也需要知道，这里指的是动态加载器(不要与 Binutils 里的标准连接器 `ld` 混淆了)。动态连接器由 Glibc 提供，用来找到并加载一个程序运行时所需的共享库，在做好程序运行的准备之后，运行这个程序。动态连接器的名称通常是 `ld-linux.so.2` ，在不怎么流行的平台上则可能是 `ld.so.1` ，而在新的 64 位平台上更可能是别的完全不同的名称。查看宿主系统的 `/lib` 目录可以确定动态连接器的名称。确定这个名称还有一个必杀技，就是在宿主系统上随便找一个二进制文件，运行 **`readelf -l <二进制文件名> | grep interpreter`** 并查看输出的内容。涵盖所有平台的权威参考请查看 Glibc 源码根目录里的 `shlib-versions` 文件。 [第五章](chapter05.html)中构建方法是如何工作的一些技术要点： * 这个过程在原理上与交叉编译类似，通过把工具安装在同一个目录(使用相同的"prefix")中以便协同工作，还利用了一点 GNU 的"魔法"。 * 小心处理标准连接器的库文件搜索路径，确保程序仅连接到指定的库上。 * 小心处理 `gcc` 的 `specs` 文件，告诉编译器要使用哪个动态连接器。 首先安装的是 Binutils ，因为 GCC 和 Glibc 的 `configure` 脚本要在汇编器和连接器上执行各种各样的特性测试，以确定软件的哪些功能要启用，哪些功能要禁用。这样做比你想像的还要重要，配置不正确的 GCC 或者 Glibc 会导致工具链出现微妙的错误，这样的错误造成的影响可能直到整个系统快要编译完成的时候才显现出来。测试程序通常会在其它的许多工作进行之前给出错误警告(以避免其后的无效劳动)。 Binutils 的汇编器和连接器安装在两个位置：`/tools/bin` 和 `/tools/$TARGET_TRIPLET/bin` ，一个位置的程序是另外一个位置的硬链接。连接器的一个重要方面是它的库搜索顺序，将 _`--verbose`_ 选项传递给 `ld` 可以获得详细的信息。例如，输入命令：**`ld --verbose | grep SEARCH`** 将显示当前搜索路径和顺序。要显示 `ld` 连接的是哪些文件，可以编译一个伪(dummy)程序并把 _`--verbose`_ 选项传递给连接器。举个例子，输入 **`gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded`** 将显示所有连接成功的文件。 第二个安装的软件包是 GCC 。下面是运行 `configure` 脚本时，输出内容的一个示例： ``` checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld ``` 基于上面提到过的原因，这是重要的步骤，它同时证明了 GCC 的配置脚本并不是搜索 PATH 里的目录来寻找要使用哪个工具的，而且，在 `gcc` 的实际操作中，相同的搜索路径不一定会被使用。要知道 `gcc` 会使用哪个标准连接器，请运行 **`gcc -print-prog-name=ld`** 命令。 在编译一个伪程序的时候，给 `gcc` 命令传递 _`-v`_ 选项可以获得详细的信息。举个例子：**`gcc -v dummy.c`** 将显示在预处理、编译和汇编各个阶段的详细信息，包括 `gcc` 文件包含的搜索路径及其顺序。 接下来安装的软件包是 Glibc 。编译 Glibc 的时候，最需要注意的地方是编译器、二进制工具(Binutils)和内核头文件。编译器一般不是问题，因为 Glibc 总是使用在 `PATH` 目录里找到的 `gcc` 。二进制工具和内核头文件则有点复杂，因此，为慎重起见，明确使用配置开关(选项)来强制进行正确的选择。在运行 `configure` 之后，请检查 `config.make` 文件的内容(位于 `glibc-build` 目录下)，查看所有重要的细节。注意，_`CC="gcc -B/tools/bin/"`_的作用是控制要使用哪个二进制工具；而 _`-nostdinc`_ 和 _`-isystem`_ 选项则是控制编译器的文件包含搜索路径。这些选项表明了 Glibc 软件包的一个重要特征：根据其编译方法，它是非常自给自足的，而且一般不依赖于工具链的默认值。 装完 Glibc 之后，需要做一些调整使得只在 `/tools` 目录里搜索和连接。安装一个调整好的 `ld` ，将它的固化搜索路径限制在 `/tools/lib` 目录。然后修改 `gcc` 的 specs 文件以指向 `/tools/lib` 目录里新的动态连接器。最后这一步在整个过程中至关重要，像上面提到的，指向动态连接器的固化路径被嵌入到每个 ELF 可执行文件里。可以通过 **`readelf -l <二进制文件名> | grep interpreter`** 命令来检查。修改 gcc 的 specs 文件以确保本章后面编译的每一个程序都使用位于 `/tools/lib` 目录里新的动态连接器。 需要使用新动态连接器也是第二遍编译 GCC 需要打 Specs 补丁的原因。不这样做的结果是 GCC 会把宿主系统 `/lib` 目录下动态连接器的名字嵌入进来，这样有悖于与宿主系统隔离的目标。 第二遍编译 Binutils 的过程中，我们利用 _`--with-lib-path`_ 选项来控制 `ld` 的库搜索路径。如前面所指出的，核心工具链是自包含和自依赖的，所以[第五章](chapter05.html)余下的软件包的编译将依赖于 `/tools` 下新的 Glibc 。 在[第六章](../chapter06/chapter06.html)进入虚根环境后，第一个安装的主要软件包就是 Glibc ，原因是上面所提到的 Glibc 自给自足的特性。一旦 Glibc 安装到 `/usr` 目录后，马上改变工具链的默认值，然后构建目标 LFS 系统的其它部分。