换个角度看LFS——反向分析LFS
来源：
作者：
时间：2008-06-22
Tag：
点击：
要解决上面这个问题，那么最好的方法就是将工具链放置在一个独立的目录中，LFS将其放在了/tools目录下，因此在用工具链建立目标系统的过程中将PATH设置为/bin:/usr/bin:/tools/bin来让 bash调用命令时能首先调用目标系统中已经建立好的命令，如果没有则从工具链中调用。这样的话在目标系统还没有编译工具的情况下使用工具链来进行编译。
好了，现在已经可以用工具链来完成目标系统的编译了，下面的问题就是这个工具链是如何来的呢？
这个问题就要回到前面所提到的工具链运行时所依赖的环境，还是这个glibc，要编译这个glibc必须是在工具链的编译工具生成之前，而工具链的编译工具又依赖于glibc，那么这个glibc就不能是现在工具链中的编译工具编译出来的，那么是谁编译的呢？
这个问题的答案：当然还是编译器编译的这个glibc和工具链里的编译工具，也就是说在工具链中的编译工具编译目标系统之前需要另一个编译器来编译这个在使用的工具链中的编译器和编译器所依赖的glibc。
用蓝色的虚线框起来的部分就是生成工具链的工具链，我暂时称为“预工具链”。
“预工具链”的存在则能完成工具链中的glibc，以及工具链中的编译工具，并且工具链中的工具将被编译成依赖于工具链中的glibc。
那么现在要解决的问题就是这个“预工具链”是如何建立起来的。
答案还是一样，需要一套编译工具来编译出这个“预工具链”。
现在要提到的一个问题就是，用不同版本的gcc编译出来的程序可能不一样，而不同的gcc编译出来的目标文件要用能正确处理的binutils的版本来链接成可执行文件，因此我们现在已经能确定的gcc、binutils版本是工具链中的版本，那么用工具链编译出来的目标系统是符合我们的要求的。
那么编译工具链中的glibc和gcc以及binutils的gcc和binutils的版本现在还没有确定，但根据LFS的“纯净”目标，也就是说 gcc和binutils也必须和工具链中的gcc和binutils相同才行。而其它的常用工具及make虽然参与，但不会对编译的二进制产生影响（前提是必须能正确处理它应该做的事情）。
现在的问题就集中到“预工具链”中的gcc和binutils上了，只要能编译出和工具链中的gcc与binutils相同版本就可以了，也就是说只要一套编译环境能编译gcc和binutils就可以了。
那么问题是这一套编译环境是怎么来的呢？
如果还继续按照前面的套路，这个问题就成了无穷无尽的了，这个不是我们想做的，现在已经能“纯净”的建立一套符合条件的工具链就已经达到我们的目的了，因此编译“预工具链”的binutils和gcc的任务我们就采用一套能正确编译的发行版或者预制好的编译环境就可以了，我们可以称这个发行版或者预制好的编译环境为“主系统”。
那么我们现在只要能用这个“主系统”编译出“预工具链”的binutils和gcc就可以了，“预工具链”中的其它部分就直接采用“主系统”里的就可以了。
但这里有一个问题就是：“主系统”中的gcc和binutils与“预工具”中要求的gcc和binutils版本不同（通常会老些），但只要能正确编译binutils、gcc就行了，gcc具备自我编译的功能，因此建议编译不同版本的gcc采用bootstrap的方式比较好。当然“主系统”中的在参与编译过程中的其它工具也需要符合要求就成。
最后用一副图来表达简单的表达整个过程，也算本文的结尾。
（转载请保持文章的完整性，请注明作者和出处）
作者：冲天飞豹（youbest）
Email:youbest@sina.com
2006年6月21日
希望大家能多写一些分析性的文章，共同提高。
说明：上图的内容实际上并不是标准的LFS编译关系，按照LFS的做法，应该在预工具链编译完成工具链中的 glibc、gcc和binutils，工具链后续的部分是由工具链的gcc和binutils来完成的，但本文并不追求和LFS完全一致，只是为了说明整个过程是如何反向推出来的，而且我认为按照图里的方法也完全没问题，完全不影响目标系统的“纯净”度。
