03.最后的准备工作

三、最后的准备工作

1.创建 $LFS/tools 目录

[root@fish lfs-packages-6.2]# mkdir -v $LFS/tools

mkdir: 已创建目录 ‘/mnt/lfs/tools’

$LFS/tools 目录里编译的程序只是（在构建临时编译环境时）临时使用的工具，不是最终 LFS 系统的组成部分。把这些程序放到一个单独的目录下，在使用过之后简单的删除掉就可以了。这样做也可以防止这些程序与宿主系统中相同的程序混淆（在构建临时编译环境时容易出现这样的事情）。

下一步是在宿主系统上创建一个 /tools 符号链接，指向 LFS 分区上新创建的目录，这个命令同样要作为 root 用户运行：

[root@fish lfs-packages-6.2]# ln -sv $LFS/tools /

创建连至‘/mnt/lfs/tools’的符号链接‘//tools’

注意

上述命令是正确的，ln 命令的语法有了一点变化。如果您认为发现了一个错误，在报告它之前，先用 info coreutils ln 和 ln(1) 命令查看手册页。

所创建的符号链接使得将要编译的工具链总是位于 /tools 目录下，这意味着编译器、汇编器和连接器在本章(这时我们还在使用宿主系统的一些工具)和构建临时编译环境(这时我们"chrooted"到了 LFS 分区)都可以使用。

2.添加 LFS 用户

以 root 用户登录的时候，犯一个错误就足以损坏甚至摧毁系统，因此，推荐使用一个无特权的用户来编译和安装软件包。为了建立一个干净的工作环境，建议新建一个名为 lfs 的组，并在其中添加一个名为 lfs 的用户，我们将在安装过程中使用这个用户。以 root 用户运行下列命令来添加新用户：

[root@fish lfs-packages-6.2]# /usr/sbin/groupadd lfs

[root@fish lfs-packages-6.2]# /usr/sbin/useradd -s /bin/bash -g lfs -m -k /dev/null lfs

命令行选项的含义：

-s /bin/bash 指定 bash 作为 lfs 用户的默认 shell -g lfs 将 lfs 用户添加到 lfs 组 -m 为 lfs 用户创建 home 目录 -k /dev/null 这个参数通过修改输入位置为特殊的空设备来防止从框架目录(默认为 /etc/skel)拷贝文件 lfs 这是所创建的组和用户的实际名字

为了可以使用 lfs 用户登录(与从 root 用户切换到 lfs 用户不同，这种切换不需要 lfs 用户有一个密码)，必须先为 lfs 用户设置一个密码：

（构建过程lfs用户密码：123456）

[root@fish lfs-packages-6.2]# passwd lfs

Changing password for user lfs.

New UNIX password:

BAD PASSWORD: it is too simplistic/systematic

Retype new UNIX password:

passwd: all authentication tokens updated successfully.

通过把 lfs 用户设置为 $LFS/tools 目录的所有者来授予 lfs 用户对该目录的完全访问权限：

[root@fish lfs-packages-6.2]# chown -v lfs $LFS/tools

‘/mnt/lfs/tools’ 的所有者已更改为 lfs

如果创建了独立的工作目录，请将该目录的所有权赋予 lfs 用户：

[root@fish lfs-packages-6.2]# chown -v lfs $LFS/sources

‘/mnt/lfs/sources’ 的所有者已更改为 lfs

接下来，以 lfs 用户登录。您可以通过一个虚拟控制台，或者通过显示管理器，或者用下面的切换用户命令：

[root@fish lfs-packages-6.2]# su - lfs

-bash-3.00$

"-" 参数指示 su 开启一个登陆Shell(login shell)而不是非登陆Shell(non-login shell)，这两种 shell 的不同之处请参考 bash(1) 和 info bash 。

3.设置工作环境

通过给 bash shell 创建两个新的启动文件来设置一个良好的工作环境。用 lfs 用户登录，输入下面的命令来创建一个新的 .bash_profile 文件：

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

-bash-3.00$ cat > ~/.bash_profile << "EOF"

> exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash

> EOF

-bash-3.00$ ls -a

. .. .bash_profile

-bash-3.00$ cat .bash_profile

exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash

-bash-3.00$

作为 lfs 用户登录的时候，初始 shell 通常是一个登陆shell(login shell)，它会首先读取宿主系统的 /etc/profile 文件(可能包含一些设置和环境变量)，然后继续读取 .bash_profile 文件来完成登录初始化。.bash_profile 文件中的 exec env -i.../bin/bash 命令用完全空的环境来取代当前的环境（除了继承 HOME, TERM, PS1 变量外）。这样能保证我们的编译环境不会被宿主系统中不必要的或者有潜在危险的环境变量所影响，从而确保获得一个干净的工作环境。

另一个新的 shell 实例是非登陆shell(non-login shell)，它不读取 /etc/profile 或 .bash_profile 文件，而是读取 .bashrc 文件。现在创建 .bashrc 文件：

cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL PATH
EOF

-bash-3.00$ cat > ~/.bashrc << "EOF"

> set +h

> umask 022

> LFS=/mnt/lfs

> LC_ALL=POSIX

> PATH=/tools/bin:/bin:/usr/bin

> export LFS LC_ALL PATH

> EOF

-bash-3.00$ ls -a

. .. .bash_history .bash_profile .bashrc

-bash-3.00$ cat .bashrc

set +h

umask 022

LFS=/mnt/lfs

LC_ALL=POSIX

PATH=/tools/bin:/bin:/usr/bin

export LFS LC_ALL PATH

-bash-3.00$

set +h 命令关闭 bash 的 hash 功能，hash 通常是一个有用的特性：bash 使用一个 hash 表来记录可执行文件的完整路径，以避免为了找到同一个可执行文件而反复搜索 PATH 里的目录。然而，新工具装好之后就要立即使用，通过关闭 hash 功能，当要运行程序的时候，shell 将总是搜索 PATH 里的目录，这样新工具一编译好，shell 就可以在 $LFS/tools 目录里找到，而不是执行所记忆的其它地方的旧版本程序。

将用户文件创建掩码(umask)设为 022 ，使得新创建的文件和目录只有所有者可写，其他用户只能读取和运行(open(2) 系统调用的默认模式是新文件权限 644，新目录权限 755)。

LFS 环境变量应该设为所选择的挂载点。

LC_ALL 环境变量控制着某些程序的本地化，使其显示的信息遵循指定国家的惯例。如果宿主系统使用的 Glibc 版本低于 2.2.4，将 LC_ALL 环境变量设置为"POSIX"或"C"以外的值(在本章中)可能会在您退出虚根环境后再想返回的时候出现问题。请把 LC_ALL 设置为"POSIX"或"C"(这两者是等价的)以确保在虚根环境中的所有东西都像预期的那样正常工作。

通过把 /tools/bin 放在 PATH 的最前面，（构建临时编译环境）中所有的程序安装好后，就可以立即被 shell 运行。将这一点和关闭 hash 功能结合起来，预防了宿主系统的旧程序在不该运行的时候却被运行了的风险。

最后，为了完全准备好编译临时工具的工作环境，导入刚刚创建的 profile 文件：

-bash-3.00$ source ~/.bash_profile

lfs:~$

4.关于SBU

许多人都想知道编译和安装一个软件包预计需要多长时间。因为 Linux From Scratch 可以在多种不同的系统上创建，准确估计所需的时间是不可能的。最快的系统上编译安装最大的软件包(Glibc)大约需要 20 分钟，但在很慢的系统上可能耗费长达三天时间。我们不提供准确时间，代之以标准编译时间单位(SBU)来度量。

SBU 度量具体说明如下，本书中第一个编译的软件包是构建临时编译环境中静态编译的 Binutils 。编译这个软件包所花费的时间就作为标准编译时间单位(SBU)。所有其它软件的编译时间都用这个时间来衡量。

例如，对于一个编译时间为 4.5 SBU 的软件包，这意味着如果一个系统静态编译安装 Binutils 需要花费 10 分钟，那么编译这个软件包将大约需要 45 分钟。幸运的是，大多数软件包编译安装所需的时间都比 Binutils 所需的时间要短。

SBU 并不十分精确，因为它依赖于许多因素，包括宿主系统 GCC 的版本。另外，在基于对称多处理器(SMP)的机器上，SBU 更加不准确。我们提供 SBU，仅仅是给出安装一个软件包所需时间的大概估计，在某些情况下实际花费的时间与预估计的时间之间可能有数十分钟的差异。

要查看在一些特定机器上的实际编译安装时间，我们推荐您查看 LinuxFromScratch SBU 的主页 http://www.linuxfromscratch.org/~bdubbs/ 。

5.关于软件包测试套件

大多数软件包提供了测试程序集。编译完一个软件包之后立即运行一下它提供的测试程序是个好主意，因为测试程序将进行一次"健全检查"来确认所有的代码是否都正确编译了。通过了测试程序集的一系列检查，通常意味着软件包在按照开发者的预期工作，但是这并不保证这个软件包就完全没有 bug 了。

某 些软件包的测试程序是极为重要的，例如核心工具链软件包 GCC 、Binutils 、Glibc 的测试程序，这是因为这些软件包在一个良好工作的系统里的处于核心角色。GCC 和 Glibc 的测试程序需要运行很长时间，尤其在速度慢的硬件上，但我们仍然强烈建议您运行这些测试程序。

注意

经验显示，运行构建临时编译环境中的测试程序时会有点小问题。不可避免的是，宿主系统总是对构建临时编译环境的测试程序施加某些影响，常常导致无法解释的测试失败。因为构建临时编译环境中编译的工具是临时的，而且在最后会被丢弃，我们不推荐中等水平的读者运行构建临时编译环境中的测试程序，这些测试程序的指令是为开发和测试人员准备的，它们不是必需的。

Binutils 和 GCC 的测试程序一个常见的问题就是在伪终端(PTY)外运行，这样可能会出现大量的测试失败。可能的原因有几个，但最可能的原因是宿主系统没有正确的设置 devpts 文件系统，这个问题在构建临时编译环境中有详细的讨论。

某些软件包测试程序可能会给出错误的失败信息，请参考 LFS Wiki http://www.linuxfromscratch.org/lfs/build-logs/6.2/ 以确认您所遇到的测试失败是否是预期会出现的。这个站点的内容对于本书所有的测试都是正确的。