鸭鸭和我补充的一些LFS-6.0译文，请项目组的兄弟校对！

csfrank

看着第二个预览版发布到现在有好久好久都没动静了 :sleep
实在看不过去了～进展太慢了～
可惜俺不懂什么xml和什么文档工具之类的东西，只会写纯文本的东西，所以排版问题还请项目组的弟兄解决了。
事实上我完全没有LFS的安装经历，现在正在边看边学习中，在这个过程中，我会尽我所能翻译几篇尚未翻译的章节，不敢保证有多高的翻译质量，请项目组的弟兄校对！
如果精力允许我将不断的在后面的跟贴中贴上我零零散散翻译的章节，直到翻译不动为止 :beat

另：gentoo版的版主，大家熟悉的小劲鸭，已经同意帮忙翻译一些未完工的章节 :p  :p  :p
其他gg-jj-dd-mm们，也拿出行动来，争取早日做完这个项目啊，总不能等官方7.0的都出来了，咱们的6.0还是停留在第二个预览版吧 :beat  :beat  :beat
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
5.04 Binutils-2.15.91.0.2 - 第一编
－－－－－－－－－－－－－－－－－－－－－
Binutils 是一组开发工具，包括连接器，汇编器和其他用于目标文件和档案的工具。

预计编译时间: 1.0 SBU
所需磁盘空间: 194 MB

Binutils 依赖于: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, and Texinfo

安装 Binutils
第一个安装的软件包是 Binutils，这非常重要，因为 Glibc 和 GCC 会针对可用的连接器和汇编器进行多种测试，以决定打开某些特性。

如果你把这个包缺省的优化参数(包括 -march 和 -mcpu参数)改变的话，它会有些不正常的表现。因此，如果你定义了任何优化参数的话，比如CFLAGS 和 CXXFLAGS，我们劝你在编译 Binutils 时 unset 或修改它们。

Binutils的安装指南推荐用一个新建的目录来编译它，而不是在源码目录中：

mkdir ../binutils-build
cd ../binutils-build

注意
如果你想利用本书余下部份列出的SBU值，那么现在就要测量一下编译本软件包的时间。你可以用类似于下面这样的命令：
time { ./configure ... && ... && ... && make install; }.

现在为编译 Binutils 作准备：

../binutils-2.15.91.0.2/configure --prefix=/tools \
    --disable-nls
配置选项的意思是：

--prefix=/tools
这个参数告诉 configure 脚本，应该把 Binutils 软件包中的程序安装到 /tools 目录中.

--disable-nls
这个参数禁止了国际化(通常简称i18n)。静态程序不需要国际化的特性，并且在静态连接时nls常常引起错误。

接下来编译它:

make configure-host
make LDFLAGS="-all-static"

make 命令参数的意思是：

configure-host
它强制所有的子目录都进行配置，如果没有这个参数，静态连接就会失败，因此我们暂且用它来解决这个问题。

LDFLAGS="-all-static"
这个参数告诉连接器，把 Binutils 软件包中所有的程序都静态连接。严格地说，首先是"-all-static" 被传递给libtool，libtool再把"-static" 传递给连接器。

现在编译完成了。通常我们会运行测试套件，但是目前测试套件(Tcl, Expect, and DejaGNU)尚未安装。而且在这里运行测试没什么好处，因为第一遍安装的程序很快就会被第二遍的程序所覆盖。

现在安装软件包:

make install

现在，为后面的"调整"glibc准备连接器:

make -C ld clean
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib

make 参数的意思是：

-C ld clean
告诉make，删除所有子目录ld里编译生成的文件。

-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib
这个选项重新编译 ld 子目录中的所有文件。LIB_PATH是 Makefile 中的一个变量，在命令行里指定它，使我们可以覆盖缺省值，并让它指向临时工具目录。这个变量的值指定了连接器的缺省库搜索路径。在这一章的稍后部分会用到。


警告

现在不能删除Binutils的编译目录和源码目录，我们在本章后面部份还要用到它们，所以请别动它们。

关于这个软件包的详细资料位于“Contents of Binutils”

csfrank

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
GCC-3.4.1 - 第一编
－－－－－－－－－－－－－－－－－－－－－
GCC 软件包包含 GNU 编译器，其中有C和C++编译器.

预计编译时间: 4.4 SBU
所需磁盘空间: 300 MB

GCC 依赖于: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, and Texinfo

安装 GCC
这里只解压 gcc-core 包，因为C++编译器和测试套件目前还不需要。

如果你把这个包缺省的优化参数(包括 -march 和 -mcpu参数)改变的话，它会有异常表现。最好不要优化这个包。因此，如果你定义了任何优化参数的话，比如CFLAGS 和 CXXFLAGS，我们劝你在编译GCC时unset或修改它们。

GCC 的安装指南推荐用一个新建的目录来编译它，而不是在源码目录中:

mkdir ../gcc-build
cd ../gcc-build

为编译 GCC 作准备:

../gcc-3.4.1/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --disable-nls --enable-shared --enable-languages=c

这些配置参数的意思是:

--with-local-prefix=/tools
这个参数的目的是把 /usr/local/include 目录从 gcc 的包含文件搜索路径里删除。这并不是绝对必要，但我们想尽量减小主系统的影响，所以才这样做。

--enable-shared
这个参数咋一看有点违反直觉。但只有加上它，才能编译出 libgcc_s.so.1 和 libgcc_eh.a, Glibc(下一个软件包)的配置脚本只有在能找到 libgcc_eh.a 时才能确保产生正确的结果。请注意，gcc的可执行程序仍然会被静态连接，因为这是由后面 BOOT_LDFLAGS 中的 -static来控制的。

--enable-languages=c
只编译 GCC 软件包中的 C 编译器。我们在本章里不需要其他的编译器。

接下来编译它:

make BOOT_LDFLAGS="-static" bootstrap

编译参数的意思是:

BOOT_LDFLAGS="-static"
这个参数要求 GCC 把它的程序静态连接。

bootstrap
bootstrap目标不仅仅是编译 GCC，而是重复编译它几次。它用第一次编译生成的程序来第二次编译自己，然后又用第二次编译生成的程序来第三次编译自己，最后比较第二次和第三次编译的结果，以确保编译器能毫无差错的编译自身，这通常表明编译是正确的。

编译现在完成了，通常我们会在这里运行测试套件，但是正如前面说过的，测试套件目前尚未安装，而且在这里运行测试没什么好处，因为第一遍安装的程序很快就会被第二遍的程序所覆盖。

安装软件包:

make install
最后，我们将创建 /tools/bin/cc 符号链接。许多程序和脚本试图运行 cc 而不是 gcc，这是为了让程序能在多种 Unix 平台上运行，并保持一致性。并不是每个人都安装 GNU CC 的。只运行 cc 把选择 C 编译器的自由留给了系统管理员，只要有这样一个符号链接指向它：

ln -s gcc /tools/bin/cc

关于这个软件包的详细资料位于 “Contents of GCC”

csfrank

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
5.08、Glibc-2.3.4-20040701
－－－－－－－－－－－－－－－－－－－－－
5.8. Glibc-2.3.4-20040701

Glibc 包含了主要的C库。这个库提供了基本例程，用于分配内存，搜索目录，打开关闭文件，读写文件，字串处理，模式匹配，算法等等。

大约编译时间: 11.8 SBU
需要磁盘空间: 800 MB

Glibc 安装依赖于: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, and Texinfo

5.8.1. Glibc 的安装

已知这个软件包在改变其默认的优化选项(包括 -march 和 -mcpu 选项)的时候会出现问题，如果任何环境变量重载了预设定义的值，比如 CFLAGS 和 CXXFLAGS，在编译 Glibc 时请取消掉它们。

一个值得注意的地方是，使用非本书建议的方法来编译 Glibc ，是把系统的稳定性做赌注。

Glibc 文档推荐在源码目录之外的一个专门的编译目录下进行编译。

mkdir ../glibc-build
cd ../glibc-build

下一步，准备编译 Glibc :

../glibc-2.3.4-20040701/configure --prefix=/tools \
    --disable-profile --enable-add-ons=nptl --with-tls \
    --with-__thread --enable-kernel=2.6.0 \
    --with-binutils=/tools/bin --without-gd --without-cvs \
    --with-headers=/tools/glibc-kernheaders

配置选项的意思是:

--disable-profile
它关掉了 profiling 信息相关的库文件编译。如果你打算做 profiling ，就省掉这个参数。

--enable-add-ons=nptl
这个开关打开Glibc的附加包NPTL作为线程库。

--with-tls
指示Glibc添加线程存储局部化(TLS)调用支持，这是NPTL正常工作所必须的。

--with-__thread
指示Glibc包含线程支持。这是正确编译TLS支持所必须的。

--enable-kernel=2.6.0
这个告诉Glibc编译支持2.6.x Linux内核的库。

--with-binutils=/tools/bin
这个参数并不是必需的。但它们能保证在编译 Glibc 时不会用错 Binutils 程序。

--without-gd
这个参数保证不编译 memusagestat 程序，这个程序会顽固地连接到主系统的库文件(libgd, libpng, libz 等等).

--without-cvs
这个参数防止在使用CVS快照时自动检查CVS从而修改Makefile文件。这个命令并不是必须的，推荐使用它的原因是它可以抑制一些恼人但无害的关于autoconf程序丢失的警告。

--with-headers=/tools/glibc-kernheaders
这个参数指示Glibc依靠"原始"内核头文件编译他自己，从而精确的知道内核的特性以根据这些特性对自己进行最佳化编译。

在这个阶段你可能会看到下面的警告：
configure: WARNING:
*** These auxiliary programs are missing or
*** incompatible versions: msgfmt
*** some features will be disabled.
*** Check the INSTALL file for required versions.
缺少或不兼容的 msgfmt 程序，这没有什么大问题，不过有时候可能会在运行测试套件的时候出问题。msgfmt程序是宿主系统Gettext应当提供的一部分。如果担心宿主系统的msgfmt有兼容性问题，你可以升级宿主系统的Gettext，也可以忽略这个问题不去管它。

编译软件包:

make

现在编译完成了。正如前面说过的，在这里运行测试没什么好处，但是如果你坚持要测试的话可以运行下列命令：

make check

关于测试失败重要性的讨论请参考章节“Glibc-2.3.4-20040701”

Glibc的测试套件高度依赖于你主系统的某些功能，尤其是内核。另外，这里某些测试可能会受主系统里工具和环境的影响，通常情况下，glibc的测试套件应该总是成功的，但因为上面的原因，有时很难避免遇到错误。总之，这里运行Glibc的测试套件出错，别太在意。第六章的Glibc才是我们最后所使用的。但要注意的是，在第六章里，有的失败还是会出现，比如math测试。

当遇到一个错误时，记录下来，再用make check继续。测试套件会从出错的地方继续进行。你也可以用make -k check来一次把测试做完。但如果你这样做的话，就要把屏幕输出记录到文件里（make -k check > ck_log ），以便最后检查到底出了多少错，哪些测试出错了。

在安装Glibc的过程中，它会警告缺少/tools/etc/ld.so.conf文件。其实这没什么关系，不过下面的命令能修正它:

mkdir /tools/etc
touch /tools/etc/ld.so.conf

现在安装软件包:

make install
不同的国家和文化，使用不同的习俗来交流。这样的习俗很多，从比较简单的时间和日期格式，到非常复杂的语言发音。GNU程序的"internationalization"(国际化，又称i18n，18表示中间的18个字母)是以locales来实现的。

注意
如果刚才没有运行测试套件，那么现在就没有必要安装locales。在下一章里面我们将会安装。
如果你一定要安装locale，请执行下面的命令：
make localedata/install-locales

为了节省时间，上一个命令（生成并安装所有的locale）的替代方案是只安装想要和需要的locale.使用 localedef 命令可以做到这一点。这个命令的信息在Glibc的代码树里的 INSTALL 文件中有详细叙述。然而，为了将来的软件包测试的通过，许多locale还是需要的，比如GCC中的libstdc++，下面的命令能安装运行测试套件所必需的最少locale:

mkdir -p /tools/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fa_IR -f UTF-8 fa_IR
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP

关于这个软件包的详细资料位于“Contents of Glibc”

csfrank

=====================================
5.09、调整工具链
----------------------------------
现在临时的C库文件已经装好，接下来本章中要编译的所有工具应该连接到这些库。为了达到这个目标，连接器和编译器的specs文件需要调整。

在第一遍编译Binutils快结束的时候，已经把连接器调整过了，通过在binutils-build目录下执行以下的命令就可安装：

make -C ld install
从现在开始，所有东西都连接到/tools/lib里面的库文件。

注意
如果前面第一遍的时候你忽略了保留Binutils源代码和编译目录的提示，就忽略前面的命令。这会有较小的机会导致测试用的一些程序连接到主机的库文件上。这当然不理想，但不是大问题。这种状况在第二遍安装Binutils的时候会被纠正过来。

现在调整过的连接器已经装好了，Binutils编译目录和源代码目录现在可以删掉了。

下面要做的是修正 GCC specs 文件，使它指向新的动态连接器。一个简单的 sed 命令就能做到:
SPECFILE=`gcc --print-file specs` &&
sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
    $SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE
推荐你拷贝和粘贴上面的命令，而不是手动输入命令。你也可以手动编辑specs文件，只要把所有的 "/lib/ld-linux.so.2" 都替换成 "/tools/lib/ld-linux.so.2" 就行了。
请用你的眼睛仔细检查一下specs文件，以确保上述修改确实生效了。

重要
如果你的系统平台上，动态连接器的名字不是ld-linux.so.2，你必须把上面命令里ld-linux.so.2
换成你的系统平台上动态连接器的名字。参见 工具链技术说明。

最后，有些主系统里的头文件会跑到gcc的头文件目录里，这可能是因为GCC的"fixincludes"脚本在编译GCC的过程中运行了。我们将在本章随后一点，详细的解释这个脚本。现在，执行下面的命令，以避免头文件混淆:
rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}

小心
现在，需要停下来确保一下新工具链的基本功能(编译和连接)是否按预期工作，运行下面的命令做一个简单的合理性检查：

echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

如果一切正常，应该不会出错，而且最后一个命令的结果是:

[Requesting program interpreter: /tools/lib/ld-linux.so.2]

注意，/tools/lib 应该是动态连接器的前缀了。

如果输出不是像上面那样或者根本没有输出，那么就有大问题了。返回并检查前面的操作，
找出问题，并改正过来。在改正之前，不要继续后面的部份，因为没什么意义。首先，再次上述合理性检查，用
gcc代替cc，如果工作正常，那么是因为/tools/bin/cc 这个符号链接丢失了。回头看看
“GCC-3.4.1- 第一遍编译”部分并暗转符号链接。接下来，确保 PATH正确。检查时，运行
echo $PATH 并检查 /tool/bin 在列表的头部。如果PATH错误，可能时因为你没有以lfs
用户登录，或者在“设置工作环境”的部分出错了。另外一个原因可能是上面修正specs文件是出
错，如果这样，重新修改specs文件，复制粘贴时小心。

在确定一切正常后，删除测试文件:
  rm dummy.c a.out

csfrank

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
5.13. GCC-3.4.1 - 第二编
－－－－－－－－－－－－－－－－－－－－
预计编译时间: 11.0 SBU
所需磁盘空间: 274 MB

安装 GCC 依赖于：Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, and Texinfo

再次安装 GCC
已知这个软件包在改变其默认的优化选项(包括 -march 和 -mcpu 选项)的时候会出现问题，如果您自定义的环境变量覆盖了这些默认选项，例如 CFLAGS 和 CXXFLAGS，请在编译 GCC 时unset 或修改它们。

测试 GCC 和Binutils所需的工具：Tcl, Expect 和 DejaGNU已经安装好。现在GCC 和Binutils 将被重新编译，连接到新的 Glibc 并作适当测试（如果运行这章中的测试的话），要注意，这些测试套件受伪终端（PTYs）的影响很大，这些终端是由主系统提供的，通过 devpts 文件系统实现。你可以用下面的方法，来测试主系统中PTY是否设置正常：

expect -c "spawn ls"

如果你得到下面的回答:
The system has no more ptys.  Ask your system administrator to create more.
说明主系统的PTY没设置好。这种情况下，运行GCC和Binutils的测试套件就没什么意义了。你需要先解决主系统中的PTY设置问题。参见 LFS Wiki(http://wiki.linuxfromscratch.org/).

现在要编译 C 和 C++ 编译器，解压core 和 g++ 压缩包（如果你要运行测试套件，再解压test套件），它们会释放到名为gcc-3.4.1/的同一子目录中。
首先纠正一个问题，并做一些调整:
patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.4.1-specs-1.patch
第一个补丁禁止GCC中"fixincludes"脚本的运行。前面提到过一些，这里再深入地看看这个脚本的作用。在通常情况下，GCC的 fixincludes脚本会搜索你的系统头文件目录，找出需要修正的头文件。比如，它可能找出主系统的glibc头文件需要修正，就把修正后的文件放到 GCC的头文件目录里。随后，在第六章里，我们安装过新的glibc后，gcc的头文件目录会排在glibc头文件目录的前面，结果就是gcc使用的头文件是从主系统里来的glibc头文件，而不是我们新安装的那个。这可能会造成不兼容。
第二个补丁修改gcc的缺省动态连接器（典型的 ld-linux.so.2）的位置，还把/usr/include从GCC的头文件搜索路径里删掉。现在安装而不是安装GCC之后调整 specs文件可以保证新的动态连接器在编译gcc的时候就用上。也就是说，随后的所有临时程序都会连接到新的glibc上。
重要: 这两个补丁 非常重要，为了成功编译，千万别忘了运用它们。

再为编译创建一个单独目录：
mkdir ../gcc-build
cd ../gcc-build

在开始编译前，别忘了unset任何优化相关的环境变量。

准备编译GCC
../gcc-3.4.1/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++ --disable-libstdcxx-pch

新配置选项的含义：

--enable-clocale=gnu:
本参数确保C++库在任何情况下都使用正确的locale模块。如果配置脚本查找到de_DE这个locale，它就会使用正确的gnu模块。然而，如果没有安装de_DE，就有可能创建出应用程序二进制接口(ABI)不兼容的C++库文件，这是因为选择了错误的generic locale模块。

--enable-threads=posix:
使c++异常能处理多线程代码。

--enable-__cxa_atexit:
使用 __cxa_atexit来代替 atexit,用来记录本地静态和全局对象的C++析构函数，这是为了完全符合标准的规定。它还会影响到C++ ABI，因此生成的C++共享库，在其他的Linux发行版上也能使用。

--enable-languages=c,c++:
本参数编译C和C++语言的编译器。

--disable-libstdcxx-pch
不为libstdc++编译预编译头（PCH），它占用了很大空间，但是我们用不到它。

编译软件包

make

现在没必要用bootstrap作为make的目标，因为这里gcc是用相同版本的gcc来编译的，其实连源码都一模一样，就是在第一遍的时候安装的那个。

现在编译完成了，早先我们谈到过，本章中的临时工具的测试程序并不是必须运行的，如果您要运行 GCC 的测试程序，请输入下面的命令：

make -k check

-k 参数是让测试套件即使遇到错误，也继续运行，直到完成。GCC 的测试套件非常全面，所以基本上总是会出一些错的。要看测试结果，用下面的命令:

../gcc-3.4.1/contrib/test_summary

通过输出管道 grep -A7 Summ ，可只输出摘要

可以把结果与贴在gcc-testresults邮件列表上的比较一下。比如，GCC-3.4.1 在i686-pc-linux-gnu平台上的结果，见：http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html

一些意外的失败总可以被忽略。GCC 的开发者通常知道这些问题，但还没有解决。只要你的测试结果和上面的URL里的结果没有太大出入，那么可以继续编译。

安装软件包

make install

注意

这里强烈建议再执行一次我们前面进行过的“合理性检查”。参见“调整工具连”小节，并重复测试 。如果结果是错误的，你很可能是忘了运用上面的Specs补丁。

csfrank

说明一下：我在翻译每个章节的时候并没有非常严格的按照原书做到每一句都对应，而是做了一些变通，仅保证在技术上不出现偏差(当然这也是尽力而为，毕竟我的水平有限，也可能理解错了原文的意思)。
我认为翻译技术文章不能和翻译文学作品采用同样的标准，虽然"信达雅"是共同的追求，但是技术文章更应当追求技术方面的阐述是否严谨和精确，而不必拘泥于原文(甚至可以修改原文某些不妥的地方)，因此可以更多的采用意译。
此乃偶的一人之见而已。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
6.01 简介
--------------------------------------
在这一章我们进入新的系统，开始精心构建LFS系统。也就是我们通过chroot命令进入一个临时的微型Linux系统，并作一些最后的准备，然后开始安装软件包。

软件的安装非常的明了。尽管许多情况下安装说明可以做的更加简短通用，但为了消除可能出现的错误，我们为每一个包都提供了全面的说明。明白每一个包的用途以及为什么用户（或系统）需用它是学习Linux系统是如何工作的关键。对每一个安装的包，我们都给出了对其内容的概要说明并对该包所安装的程序和库也作了简要的描述。

如果在本章中进行编译器优化，那么请看看编译器优化提示：
http://www.linuxfromscratch.org/ ... es/optimization.txt
［译者注］也可以看看另一个帖子：http://www.linuxsir.cn/bbs/showthread.php?t=222670
编译器优化可以使程序运行的稍快一些，但也会出现某些编译问题。如果某个包在使用优化的情况下无法通过编译，试试不用优化编译能不能解决问题。即使使用优化编译成功，由于源码与编译工具之间复杂的相互作用，程序仍有可能被错误的编译了。使用编译器优化得到的小幅度性能提升，与它带来的风险相比微不足道。所以初次编译LFS的用户最好不要使用任何优化。那样，系统依然会又快又稳定。

本章中包的安装顺序应当严格遵守，以确保没有一个程序会把/tools 作为路径硬连接到代码中。同样不要并行编译包。并行编译可能会节省时间（特别是在双CPU的机器上），但也可能造成程序包含/tools硬连接路径，以致在tools目录删除之后，程序无法运行。

在安装说明之前，每个安装页都提供了有关该包的信息，包括：对其内容的简要说明，编译大约所用的时间，编译过程所需磁盘空间以及成功编译所需的其它的包。在安装说明之后有该包所安装程序和库的列表以及对它们的简要说明。

你可以使用一个包管理工具来跟踪每个包安装和修改了那些程序。你可以参考下列页面看看各种不同风格的包管理工具：
http://www.linuxfromscratch.org/ ... tion/important.html
有一个我们推荐的特别适合于LFS的管理包的方法请参见：http://www.linuxfromscratch.org/ ... rol_and_pkg_man.txt.


注意
这本书剩余的部分我们将以root用户登陆，而不再是lfs用户。

csfrank

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
6.08 创建设备
－－－－－－－－－－－－－－－－
创建初始设备节点
内核在引导系统时要求某些设备节点必须存在(特别是console和null)，我们用下面的命令来创建它：

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3


挂载ramfs并填充/dev目录
理想的向/dev目录填充设备的方法是在/dev上挂载一个虚拟文件系统，比如tmpfs，然后每一次引导系统时都在这个虚

拟文件系统上创建设备。既然现在新的系统尚未被引导，那么就有必要通过挂载/dev来手工完成Bootscripts将来要做

的事情。
先挂载/dev
mount -n -t ramfs none /dev

运行已安装的udevstart程序并根据/sys中的信息来创建初始设备：

/tools/sbin/udevstart

有一些在系统启动的时候由Bootscripts创建的符号连接和目录是LFS所必须的。
现在创建它们：
ln -s /proc/self/fd /dev/fd
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/1 /dev/stdout
ln -s /proc/self/fd/2 /dev/stderr
ln -s /proc/kcore /dev/core
mkdir /dev/pts
mkdir /dev/shm

最后在新建的目录中挂载虚拟内核文件系统：
mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm

上面的命令可能会导致下面的警告信息：
can't open /etc/fstab: No such file or directory.

因为虽然在挂载时需要/etc/fstab文件的指示，但是该文件目前尚未被创建，不过你可以放心的忽略它。

Quanm

收到，今天晚上就来整理。

csfrank

不好意思，临时有事要忙，需要暂停几天～对不住了！不过回来了以后一定会继续努力的！

csfrank

该贴报废，请查看新贴：
http://www.linuxsir.cn/bbs/showthread.php?t=224152