换个角度看LFS——反向分析LFS
来源：
作者：
时间：2008-06-22
Tag：
点击：
清楚了这个问题，下面需要解决的就是这个运行环境从哪里来的呢？
通常Linux下的软件都提供了源代码，我们可以用这些源代码来组合成我们自己需要的二进制程序。
在这个例子中，我们想要有一个VIM，那么我们要先下载一份VIM的完整源代码，然后利用一组编译工具来完成VIM的编译。
对于一个通常编译的过程大致如下图
这其中最复杂的就是make阶段，make会调用目录中的Makefile来执行一系列的工作，其中包括创建必要的文件，以及调用gcc和binutils来编译源代码和链接目标文件，最终生成需要的可执行文件和附属文件。
所以make过程中一般需要用到的是gcc,binutils,make和一些系统程序（不同的软件需求不同）。
这样我们再来画最开始的运行环境的图
好了，这样我们就清楚了这个整个运行时候的环境是从哪里来的了。用红色虚线框起来的就是整个构造运行时环境的必要条件了，其实就是我们通常在LFS中最常见到的一个词汇：工具链。
那么下面的一个问题就是这些工具运行的条件是什么？
这些编译环境中的应用程序也和其它程序一样必须有运行的环境：
GCC依赖于glibc
binutils依赖于glibc
make依赖于glibc
头文件是在编译时候gcc所需要的，但本身都是一些文本文件，因此没有需要的运行环境。
常用工具依赖于glibc和各种需要用到的动态库。
这里的一个新问题就是编译环境中使用的glibc和Linux内核和“运行时环境”中的glibc与Linux内核是否是同一个。
答案很显然，绝对不是，因为“运行时环境”中的glibc和Linux内核是依靠工具链中编译工具来完成的，所以工具链所依赖的glibc和Linux内核于目标系统的不可能是同一个（但版本什么的是可以一样的，这里说的不同是指已经编译成二进制的实体不同）。
说明：
为了说明方便，下面将“运行时环境”称为目标系统。
但就LFS而言目标就是要做一个通用的可自主扩展（编译）的系统，所以在完成目标系统的glibc后又编译了一整套工具链中的东西，目的是将工具链中的工具全部移植到目标系统中，以便在完成目标系统后可以抛弃工具链而又能够自主的进行编译，而这些工具依赖的环境就是目标系统的glibc了。
内核这东西比较特殊，虽然运行任何程序都需要用的内核，但本身在制作目标系统过程中，目标系统的Linux内核却不需要先进行编译，因为使用Linux内核并不像glibc那样是依靠动态链接库的方式被调用的，内核不是用动态库的方式被调用的,因此不需要先编译,只要提供对应的头文件即可,后面将不再探讨 Linux内核的问题。
作为LFS的另一个目标就是要建立一个“纯净”的系统，因此编译glibc的编译器和最后目标系统里的编译器应该保持一致，同时目标系统是完全依靠工具链编译出来的，而工具链应该是在目标系统建立完毕后可以很方便的剥离掉的，而且为了保持工具链的稳定工具链中的工具所依赖的glibc以及其它用到的动态库应该是不会被替换掉的。
0
上一篇：没有了
下一篇：如何提高LFS的成功率以及部分问题的解决方法
下一篇：如何提高LFS的成功率以及部分问题的解决方法
最新评论共有 0 位网友发表了评论
查看所有评论
发表评论
热点关注