1．这个过程在原理上与交叉编译类似，通过把工具安装在同一个目录(使用相同的“prefix”)中以便协同工作，还利用了一点 GNU 的 “magic”。

2．小心处理标准连接器的库文件搜索路径，确保程序仅连接到指定的库上。

3．小心处理 Gcc 的 specs 文件，告诉编译器要使用哪个动态连接器。

下面看看具体时如何实现的。

为了创建一个干净的工作环境，在宿主系统中新创建一个lfs用户组，并添加了lfs用户，在安装过程中将一直使用该用户。

首先编译Binutils ，这时是使用宿主系统的环境。毫无疑问现在利用Binutils生成的程序会受到宿主系统的。例如：使用生成的ld（标准连接器）程序将会连接到默认的/lib目录（宿主系统）下的二进制文件。

然后编译Gcc，仍然需要宿主系统的环境。显然Gcc也受宿主系统的影响，这可以从它的编译来看，它依赖的是宿主的Glibc，而Binutils可以使用刚生成的。Glibc提供了动态连接器，用来找到并加载一个程序运行时所需的共享库，在做好程序运行的准备之后，运行这个程序。此时生成的Gcc会使用/lib（宿主系统）下的动态连接器，而不是$LFS/tools/lib下的。

通过上面两步，我们就可以使用刚生成的bintuils和Gcc来编译Glibc了。现在我们将bintuils、Gcc和Glibc都重新编译了一次。接下来就要通过调整工具链来解决刚提到的两个问题。一是重新编译ld，将ld连接到$LFS/tools/lib下的函数库。二是调整动态连接器，修改Gcc的SPEC文件，将动态连接器连接到/tools/lib/ld-Linux.so.2（ld-Linux.so.2是动态连接器的名字）。

到这里看似可以编译其它的工具了，但是接下来的工作并不是如此，而是再次编译了bintuils和Gcc，然后用第一次生成的`Glibc和现在生成的bintuils、Gcc来编译其它的工具，整个临时环境才搭建成功。

这里有个问题是为什么要将Bintuils和Gcc编译两次，可以直接用宿主系统？第一次编译bintuils和Gcc的目的一方面是为了编译Glibc；另一方面是为了能自己编译出第二遍的Gcc，即使得Gcc是自我编译的。如果直接使用宿主系统可以满足编译Glibc的要求，但是Gcc就不是自我编译了。这里为了保证制造的正确性以及使Gcc是自我编译，所以Binutils和Gcc比其它的工具都多编译一次。

接下面其它工具的编译都是使用第二次编译的Binutils和Gcc以及第一次编译的Glibc。至此，工具链就准备好了，我们可以利用这些工具生成最终的系统。同样最先生成的软件还是Binutils和Gcc，不过在编译它们之前，我们先编译出Glibc，它也是我们最终需要的C库。再次调整工具链，让随后编译的工具都连接到这个库上。不难理解，在前面的调整中我们将工具链使用的库从宿主系统转向新安装的库目录。同样，现在将工具链所使用的库从临时的库转向LFS系统最终的库目录。

系统中的其它软件都是由最新编译的Binutils、Gcc和Glibc编译的。最后就是经过配置一些简单的系统启动脚本、创建fstab文件、编译内核并安装引导程序，最终的LFS系统就可以启动了。

五、LFS的扩展

通过上面的大致的过程：通过宿主系统搭建了临时的工具链，然后通过工具链构建了最终的目标系统LFS。将LFS建成以后，就可以脱离临时编译环境。本文所说的编译都是相同的平台，前面也提到构造临时编译环境的原理与交叉编译环境相似，结合我们搭建交叉编译环境的过程，如果我们搭建的临时工具链是一个交叉编译环境，最终就应该可以实现一个跨平台的目标系统。当然具体的细节问题还需要进一步探讨。

六、小结

直接从源代码构建Linux操作系统，不仅能够定制自己理想的操作系统，更重要的通过构造LFS能够加强我们了解Linux内部是如何工作。对于有志Linux系统的人，这个构造很有必要。同时，我们应该抓住开放源代码的机遇，认真研究，同时做出自己的贡献，推进其。



[1] 王景中． Linux安全最大化．出版社.2000.5.P3．

[2] Gerard Beekmans. http://www.linuxfromscratch.org．

[3] http://youbest.cublog.cn/ ．换个角度看LFS——反向分析LFS. 2006.6．

[4] http://www.linuxsir.org/bbs/showthread.php?t=240687. LFS (版本6.1.1) 安装心得．