软件包构建注意事项

在第 2 章跟随小白构建宿主机的读者应该已经安装过软件包了，但是从第 3 章开始，我们无法使用软件包管理器安装软件，所有的软件需要手动编译。为此一些注意事项，请务必遵守。

3.1.1 通用编译指南

首先，对于每一个软件包的构建顺序大致如下：

1. 使用 tar 指令，解压软件包 ¹。
2. 进入解压得到的目录中。
3. 根据操作指导和说明进行编译。
4. 返回/mnt/lfs/sources/目录。
5. 删除解压得到的目录。

不过实际软件包的版本会随着 LFS 的版本而升级，所以读者如果实际构建的 LFS 版本高于本书的版本时，请注意随机应变。

还有几点需要注意的，在开始前再自检一下：

1. 当前宿主环境已满足 2.1.2 节中对于宿主系统的要求。
2. 所有软件包的源文件和补丁存放在 chroot 环境可访问的目录。例如，/mnt/lfs/sources/。
3. 输入 echo $LFS 检查一下环境变量 LFS。如果你完全按照本书指导操作，正确的输出结果应该是/mnt/lfs。

3.1.2 软件包构建时间单位 SBU

在着手构建软件包之前，不少人想知道构建和安装一个软件包到底需要多长的时间。不过由于硬件的差异，会指令执行效率不尽相同。就好比，i3 和 i7 其性能本身存在差异，所以显然不能使用绝对时间作为度量单位。由此便诞生了 SBU（Standard Build Unit，标准构建单元）作为相对的时间度量值来统计构建所需耗费的时间。将第 3 章第一个构建的软件包 Binutils 构建的时间作为一个一个标准构建单元，即 1 SBU。而其他软件包的构建耗时也只需要按照本章节的构建时间推算即可获得。 举个例子，如果你在本节的构建工程中消耗了 1 分钟，那么下节的交叉编译的 GCC 将需要 11SBU，也就是 11 分钟。第 3 章的 SBU 值和磁盘空间均是不包含测试套件的数值，后续章节如包含必要的测试，会另行标注测试需要花费的时间。

3.1.3 关于测试套件

很多软件包都提供相应的测试套件。为新构建的软件包运行测试套件是非常好的习惯，因为这样做可以“保证”所有功能都已编译正确。经由一系列的测试，套件往往能够检查出软件包的功能是否都如开发人员预想的那样。然而，这并不能保证所测试的软件包万无一失。

有一些相较而言更为重要的测试套件。例如，核心工具链软件包 GCC、Binutils 和 Glibc 对于一个系统的正常运转起到至关重要的作用。即使这些软件包的测试套件需要花费比较长的时间，特别是对于硬件比较慢的设备来说可能会很难熬，但还是强烈推荐完成这些测试！

除此之外，并不推荐在第 3 章中运行测试套件。因为就是宿主机或多或少会对测试产生影响，经常导致一些令人摸不着头脑的错误信息，而这个的现实无法回避。而在第 3 章中构建的这些工具只是临时的，构建完成的 LFS 并不需要它们，所以并不推荐普通读者在第 3 章中运行测试套件。虽然为测试者和开发者提供了测试套件的说明，但是这依旧是可选项。

有一部分测试套件运行的错误，是 LFS 维护人员知道但觉得不重要的。可以查看 http://www.linuxfromscratch.org/lfs/build-logs/10.0/中的日志，以确认这些失败信息是否是这些处于意料之中的错误。链接地址存放的错误消息涉及的内容基本涵盖了全书所有的测试，包括后续章节的测试结果。