本小节解释一下LFS编译方法的技术细节。没必要现在就把本节搞懂，因为真正安装过以后，会有更深的体会。以后遇到问题，可以回过头来参考本节的内容。
第五章的目的是提供一个合理的临时环境，以便我们在第六章能chroot进去，并在里面创建干净的LFS系统。为了做到这一点，我们希望与主系统关系越少越好，因此才创建一个自给自足的工具链。整个编译过程，既考虑要让新手遇到最少问题，又考虑了给读者提供最多的教育知识。也就是说，还有很多高级技术，可以用来创建这样的系统。
重要: 接着读下去以前，你需要确定一下工作平台的名称，也称作 target triplet.对多数人来说，都是i686-pc-linux-gnu. 确定工作平台的一个简单方法，是运行很多软件包都有的 config.guess 脚本。解压 Binutils 的源码，并运行./config.guess，看看结果说什么。
你还需要注意你的工作平台上动态连接器的名字，也被称为动态加载器，别与标准连接器ld搞混了，后者是binutils的一部份，而动态连接器是Glibc提供的，负责寻找和加载程序所需的共享库。对多数人来说，它的名字是ld-linux.so.2。在比较少见的平台上，它可能叫ld.so.1，在新的 64 位平台上，可能名字完全不同。你可以查看主系统中/lib目录的内容来确定动态连接器的名字。一个更保险的办法，是用下面的命令来检查主系统中的任何一个二进制程序:'readelf -l <name of binary> | grep interpreter'并观察结果。关于所有平台的参考在Glibc源码目录里的shlib-versions 文件中。
第五章编译方法能顺利进行的几个关键技术要点：
原理与交叉编译相同，把工具装在同一个前缀下，并利用一点GNU的魔力。
小心地处理标准连接器的库搜索路径，以保证程序只连接到我们选择的库上。
小心地处理gcc的specs文件，告诉编译器该使用哪个动态连接器。
首先安装 Binutils 是因为 GCC 和 Glibc 在运行./configure 脚本的时候，会针对汇编器和连接器做种种测试，以决定打开或关闭某些功能。这里的重要性比你想像的大得多！配置不正确的GCC和Glibc会组成一个有点缺陷的工具链，这种缺陷可能开始还看不出来，到LFS的最后部份才显示出来，那前面的就都白做了。幸好我们还有测试套件，以免浪费太多时间。
Binutils 安装汇编器和连接器在两个目录下：/tools/bin 和 /tools/$TARGET_TRIPLET/bin。一个路径下的工具很难连接到另一个路径下。另一个连接器的特性是库文件搜索顺序。用 ld 命令加上 --verbose 参数可以得到详细信息。比如：'ld --verbose | grep SEARCH' 会告诉你当前的搜索路径和它们的顺序。你可以看到什么文件被 ld 连接，只要编译一个简单程序被使用 --verbose参数。例如： 'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded' 会告诉你在连接过程中所有成功打开的文件。
下一个安装的软件包是GCC，在运行./configure的时候，你将看见类似下面的内容：
这也很重要。它证明GCC的configure脚本不是靠搜索$PATH目录来决定使用什么工具的。在gcc的实际运行中，搜索路径可能用不到。你可以用下面的命令来看看 gcc会使用哪个标准连接器。'gcc -print-prog-name=ld'.在编译一个简单程序时向 gcc 传递 -v 参数，可以得到详细信息。例如： 'gcc -v dummy.c' 会告诉你关于预处理器，编译和汇编阶段，以及gcc的头文件搜索路径及顺序等的详细信息。
下一个软件包是 Glibc. 编译 Glibc 时最重要的是编译器，二进制工具和内核头文件。编译器通常没什么问题，因为Glibc总是使用$PATH目录里找到的 gcc。二进制工具和内核头文件就有点麻烦了，因此我们采用保险的方法，使用可用的configure开关来强制特定选择。在运行./configure后，你可以检查一下config.make 文件的内容，它在glibc-build目录里，有很多重要细节。你会发现一些有趣的细节，比如用CC="gcc -B/tools/bin/"来控制使用哪一个二进制工具，用 -nostdinc 和 -isystem 参数来控制编译器的头文件搜索路径。这些都强调了glibc软件包的一个重要特征：在编译时，它是相当自给自足的，不太依赖于工具链的缺省值。
在安装了Glibc后，我们会做一下调整，确保路径搜索和连接只发生在 /tools 前缀下。我们安装调整过的 ld，它含有对 /tools/lib的硬路径搜索引用。然后我们修改 gcc的 specs 文件，指向 /tools/lib 下的新动态连接器。最后一步对整个过程很重要，前面说过，对动态连接器的引用是作为硬路径嵌入每一个ELF共享程序中的，你可以用：'readelf -l <name of binary> | grep interpreter'来验证。通过修正 gcc的specs文件，我们确保从这里开始直到第五章结束，每个程序都使用 /tools/lib下的动态连接器。
因为要使用新的动态连接器，所以我们才要对第二遍的GCC打specs补丁。如果不这么做，GCC自身会含有对主系统的/lib目录的硬路径引用，这会有影响我们与主系统分离的目标。
在第二遍安装 Binutils时，我们可以利用--with-lib-path来控制ld的库搜索路径。从这里开始，核心工具链已经自给自足了。第五章的随后部份都会连接到/tools下的新Glibc上，这样就对了。
第六章进入chroot环境后，我们第一个安装的重要软件包是Glibc，前面我们说过，它具有自给自足的性质，只要把它安装到 /usr前缀下以后，我们再把工具链改变回缺省值,然后就能进行余下的LFS系统安装了。
除了特殊的任务外，许多程序还要执行很多常用和琐碎的操作，比如分配内存，搜索目录，打开和关闭文件，读写它们，操作字符串，模式匹配，数学计算等等。为了避免让每个程序都“重新发明轮子”(意为重复的创新)，GNU 系统以库文件的方式提供这些基本功能和函数。任何一个 Linux 系统中最重要的库都是 glibc。
将库文件中的函数连接到使用它们的程序中，有两种方法：静态连接或动态连接。当一个程序是静态连接时，它使用的函数会包含在可执行文件中，结果就是比较大的执行文件。当一个程序是动态连接时，可执行文件中包含的是针对连接器的引用，说明了要使用的库文件名称，以及使用的函数名称，结果就是执行文件要小多了。这个可执行文件在某种程度上比静态连接的要慢，因为在运行时连接要花一些时间。(还有第三种方法，是使用动态连接器的可编程接口，参见dlopen的man文档，以获得更多信息。)
动态连接是Linux上的缺省用法，有三个主要的优点。首先，你只需要在硬盘上有一份可执行的库文件代码，而不是在不同程序里有很多份相同的代码 -- 这样就节省了硬盘空间。第二，当几个程序同时使用同样的库函数，只需要有一份函数代码存在于内存中 -- 这样就节省了内存。第三，当库函数修正了一个 bug 后，或是做了某种程度的改进后，你只需要重新编译这个库文件，而不是重新编译所有使用已改进函数的那些程序。
为什么我们要在本章的前两个软件包里使用静态连接呢？有三方面的原因，历史原因，教育价值和技术考虑。历史上来说，以前的LFS第五章里使用静态连接来编译每一个程序。教育价值在于了解动态连接和静态连接的区别是非常有用的。从技术上说，我们可以得到独立于主系统的可执行文件。然而，应该注意，即使前两个软件包是动态连接的，还是能成功的编译LFS系统。