4.Final preparations

4.1 Introduction

在本章中，我们将为构建临时系统进行一些额外的准备工作。我们将在 $LFS 中创建一些目录 (用于安装临时工具)，增加一个非特权用户并为该用户建立合适的构建环境。我们还将解释 LFS 软件包构建时间长度的测量单位 (“SBU”) 的概念，并给出关于软件包测试套件的一些信息。

4.2 Creating a Limited Directory Layout in the LFS Filesystem

在本节中，我们开始将组成最终的 Linux 系统的内容填充到 LFS 文件系统中。首先，在 LFS 分区中创建一个有限的目录树，使得在第 6 章中编译的程序 (以及第 5 章中的 glibc 和 libstdc++) 可以被安装到它们的最终位置。这样，在第 8 章中重新构建它们时，就能直接覆盖这些临时程序。

以 root 身份，执行以下命令创建所需的目录布局：

mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin}

for i in bin lib sbin; do
  ln -sv usr/$i $LFS/$i
done

case $(uname -m) in
  x86_64) mkdir -pv $LFS/lib64 ;;
esac

在第 6 章中，会使用交叉编译器编译程序 (更多细节可以在工具链技术说明一节找到)。这个交叉编译器会被安装到一个专用的目录中，从而将其和其他程序分离。仍然以 root 用户身份，执行以下命令创建该目录：

mkdir -pv $LFS/tools

注意

LFS 编辑团队特意决定不使用 /usr/lib64 目录。本书中的一些步骤保证工具链不使用该目录。如果该目录被创建，无论原因如何 (可能是您在使用书中的命令时出现了偏差，或您在完成 LFS 构建后安装了一个创建该目录的二进制包)，则它可能破坏您的系统。您应该经常检查并确认该目录不存在。

4.3 Adding the LFS User

在作为 root 用户登录时，一个微小的错误就可能损坏甚至摧毁整个系统。因此，我们建议在后续两章中，以非特权用户身份编译软件包。您或许可以使用自己的系统用户，但为了更容易地建立一个干净的工作环境，我们将创建一个名为 lfs 的新用户，以及它从属于的一个新组 (组名也是 lfs)，并在安装过程中以 lfs 身份执行命令。为了创建新用户，以 root 身份执行以下命令：

groupadd lfs
useradd -s /bin/bash -g lfs -m -k /dev/null lfs

命令行中各选项的含义:

-s /bin/bash

设置 bash 为用户 lfs 的默认 shell。

-g lfs

添加用户 lfs 到组 lfs。

-m

为用户 lfs 创建一个主目录。

-k /dev/null

将模板目录设置为空设备文件，防止从默认模板目录 (/etc/skel) 复制文件到新的主目录。

lfs

这是新用户的名称。

如果希望以 lfs 身份登录，或从一个非 root 用户切换到 lfs 用户 (这与从 root 切换到 lfs 不同，后者不需要 lfs 用户设有密码)，则需要为 lfs 用户设置密码。以 root 用户身份，执行以下命令设置密码：

passwd lfs

将 lfs 设为 $LFS 中所有目录的所有者，使 lfs 对它们拥有完全访问权：

chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown -v lfs $LFS/lib64 ;;
esac

注意: 在某些宿主系统上，下面的 su 命令不会正确完成，而会将 lfs 用户的登录会话挂起到后台。如果提示符 “lfs:~$” 没有很快出现，输入 fg 命令以修复这个问题。

下面启动一个以 lfs 身份运行的 shell。这可以通过在虚拟控制台登录 lfs 用户完成，也可以使用下面的命令切换用户：

su - lfs

参数 “-” 使得 su 启动一个登录 shell，而不是非登录 shell。bash(1) 和 info bash 详细介绍了它们的区别。

4.4 Setting Up the Environment

为了配置一个良好的工作环境，我们为 bash 创建两个新的启动脚本。以 lfs 的身份，执行以下命令，创建一个新的 .bash_profile：

cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF

在以 lfs 用户登录或从其他用户使用带 “-” 选项的 su 命令切换到 lfs 用户时，初始的 shell 是一个登录 shell。它读取宿主系统的 /etc/profile 文件 (可能包含一些设置和环境变量)，然后读取 .bash_profile。我们在 .bash_profile 中使用 exec env -i…/bin/bash 命令，新建一个除了 HOME, TERM 以及 PS1 外没有任何环境变量的 shell 并替换当前 shell。这可以防止宿主环境中不需要和有潜在风险的环境变量进入构建环境。

新的 shell 实例是非登录 shell，它不会读取和执行 /etc/profile 或者 .bash_profile 的内容，而是读取并执行 .bashrc 文件。现在我们创建一个 .bashrc 文件：

cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
EOF

.bashrc 中设定的含义：

set +h

set +h 命令关闭 bash 的散列功能。一般情况下，散列是很有用的 —— bash 使用一个散列表维护各个可执行文件的完整路径，这样就不用每次都在 PATH 指定的目录中搜索可执行文件。然而，在构建 LFS 时，我们希望总是使用最新安装的工具。关闭散列功能强制 shell 在运行程序时总是搜索 PATH。这样，一旦$LFS/tools/bin 中有新的工具可用，shell 就能够找到它们，而不是使用之前记忆在散列表中，由宿主发行版提供的 /usr/bin 或 /bin 中的工具。

umask 022

将用户的文件创建掩码 (umask) 设定为 022，保证只有文件所有者可以写新创建的文件和目录，但任何人都可读取、执行它们。(如果 open(2) 系统调用使用默认模式，则新文件将具有权限模式 644，而新目录具有权限模式 755)。

LFS=/mnt/lfs

LFS 环境变量必须被设定为之前选择的挂载点。

LC_ALL=POSIX

LC_ALL 环境变量控制某些程序的本地化行为，使得它们以特定国家的语言和惯例输出消息。将 LC_ALL 设置为 “POSIX” 或者 “C”(这两种设置是等价的) 可以保证在交叉编译环境中所有命令的行为完全符合预期，而与宿主的本地化设置无关。

LFS_TGT=(uname -m)-lfs-linux-gnu

LFS_TGT变量设定了一个非默认，但与宿主系统兼容的机器描述符。该描述符被用于构建交叉编译器和交叉编译临时工具链。工具链技术说明将提供关于这个描述符的更多信息。

PATH=/usr/bin

许多现代 Linux 发行版合并了 /bin 和 /usr/bin。在这种情况下，标准 PATH 变量应该被设定为 /usr/bin，以满足第 6 章所需。否则，后续命令将会增加 /bin 到搜索路径中。

if [ ! -L /bin ]; then PATH=/bin:$PATH; fi

如果 /bin 不是符号链接，则它需要被添加到 PATH 变量中。

PATH=$LFS/tools/bin:$PATH

我们将 $LFS/tools/bin 附加在默认的 PATH 环境变量之前，这样在第 5 章中，我们一旦安装了新的程序，shell 就能立刻使用它们。这与关闭散列功能相结合，降低了在第 5 章环境中新程序可用时错误地使用宿主系统中旧程序的风险。

CONFIG_SITE=$LFS/usr/share/config.site

在第 5 章和第 6 章中，如果没有设定这个变量，configure 脚本可能会从宿主系统的 /usr/share/config.site 加载一些发行版特有的配置信息。覆盖这一默认路径，避免宿主系统可能造成的污染。

export …

上述命令设定了一些变量，为了让所有子 shell 都能使用这些变量，需要导出它们。

重要

一些商业发行版未做文档说明地将 /etc/bash.bashrc 引入 bash 初始化过程。该文件可能修改 lfs 用户的环境，并影响 LFS 关键软件包的构建。为了保证 lfs 用户环境的纯净，检查 /etc/bash.bashrc 是否存在，如果它存在就将它移走。以 root 用户身份，运行：

[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE

当不再需要 lfs 用户时 (第 7 章一章开始后)，您 (如果希望的话) 可以复原 /etc/bash.bashrc 文件。

注意我们将会在第 8.34 节 “Bash-5.2.15”中构建的 LFS Bash 软件包未被配置为读取或执行 /etc/bash.bashrc，因此它在完整的 LFS 系统中没有作用。

最后，为了保证构建临时工具所需的环境准备就绪，强制 bash shell 读取刚才创建的配置文件：

source ~/.bash_profile

4.5 About SBUs

许多人想在编译和安装各个软件包之前，了解这一过程大概需要多少时间。由于 Linux From Scratch 可以在许多不同系统上构建，我们无法直接给出估计时间。例如，最大的软件包 (gcc) 在最快的系统上只要大约 5 分钟就能构建好，而在一些较慢的系统上需要若干天！因此，我们不提供实际时间，而是以标准构建单位 (SBU) 衡量时间。

下面给出标准构建单位的测量方法。本书中构建的第一个软件包是第 5 章中的 Binutils，定义使用单个 CPU 核心编译它需要的时间为标准构建单位，缩写为 SBU。其他软件包的编译时间用 SBU 为单位表示。

例如，考虑一个编译时间是 4.5 SBU 的软件包。如果在您的系统上，需要 10 分钟来编译和安装第一轮的 Binutils，那么大概需要 45 分钟才能构建这个软件包。幸运的是，多数软件包构建时间比 Binutils 少。

SBU 不是完全准确的，这是由于它受到许多因素的影响，包括宿主系统的 GCC 版本。SBU 只能用来估计安装一个软件包可能需要的时间，估计结果的误差在个别情况下可能达到几十分钟。

注意

对于许多拥有多个处理器 (或处理器核心) 的现代系统，可以显著缩短软件包的编译时间，设置环境变量或者直接告诉 make 命令有多少个可用的处理器，即可进行并行构建。例如，一块 Intel i5-6500 CPU 可以支持 4 个同时运行的进程，可以设定：

export MAKEFLAGS='-j4'

或者用以下命令构建：

make -j4

如上使用多个处理器时，使用 SBU 估计构建时间会出现更大的误差。某些情况下，还会导致 make 命令失败。另外，分析构建过程的的输出也会变得困难，因为不同进程的输出行会交错在一起。如果在构建过程中出现问题，需要使用单处理器进行构建，才能更好地分析错误消息。

我们给出的 SBU 值根据使用四个 CPU 核心 (-j4) 的计时计算。第 8 章中的时间还会包含运行软件包退化测试的时间，除非另有说明。

4.6 About the Test Suites

多数软件包提供测试套件，一般来说，为新构建的软件包运行测试套件是个好主意，这可以进行一次 “完整性检查”，从而确认所有东西编译正确。如果测试套件中的所有检验项目都能通过，一般就可以证明这个软件包像开发者期望的那样运行。然而，这并不保证软件包完全没有错误。

某些软件包的测试套件比其他的更为重要。例如，组成核心工具链的几个软件包 — GCC、Binutils 和 Glibc 的测试套件就最为重要，因为这些软件包在系统的正常工作中发挥中心作用。GCC 和 Glibc 的测试套件需要运行很长时间，特别是在较慢的硬件上，但我们仍然强烈推荐运行它们。

注意在第 5 章和第 6 章中运行测试套件没有意义，因为测试程序是使用交叉编译器编译的，可能无法在构建它们的宿主系统运行。

在运行 Binutils 和 GCC 的测试套件时，较常见的问题是伪终端 (PTY) 被耗尽。这会导致大量测试出现失败结果。这种现象有多种可能原因，但最常见的原因是宿主系统没有正确设置 devpts 文件系统。关于这个问题的更多细节在 https://www.linuxfromscratch.org/lfs/faq.html#no-ptys 中进行了讨论。

一些软件包的测试套件由于开发者已经知道的原因而失败，且这些失败已被判定为并不重要。参照 https://www.linuxfromscratch.org/lfs/build-logs/11.3/ 中的构建日志，来检查这些失败是否符合预期。本书中的所有测试结果都可以在该网址查询。