我们先来看CLFS2.0第一编译GCC&＃xff0c;没有使用make bootstrap来编译&＃xff0c;而是使用make all-gcc来编译&＃xff0c;也就是只编译了一次&＃xff0c;这是合情合理的&＃xff0c;要知道这个gcc是交叉版本&＃xff0c;也就是说它再编译出来的是目标体系平台的二进制文件&＃xff0c;虽然可以 完成make bootstrap的第二步&＃xff0c;但第三步是无法进行的&＃xff0c;因为目标体系平台无法在当前平台上运行&＃xff08;make bootstrap&＃xff0c;就是用第一遍编译的gcc来编译第二遍的gcc&＃xff0c;再用第二遍的gcc编译第三遍的gcc&＃xff0c;然后比较第二遍和第三遍的gcc&＃xff0c;来确定编 译是否正确&＃xff09;&＃xff0c;因此这里只需要也只能编译一遍。
在LFS里&＃xff0c;第一遍gcc只编译了c语言部分&＃xff0c;是因为编译glibc只需要c语言就行了&＃xff0c;你当然也可以编译其它的语言支持&＃xff0c;但没有什么意义&＃xff0c;因为第一遍的gcc会被第二遍替换掉&＃xff0c;而且第一遍是依赖于主系统glibc的&＃xff0c;所以在chroot后就不能用了。
在CLFS2.0里没有chroot的过程&＃xff0c;所以无论是工具链中的第一遍还是第二遍编译&＃xff0c;gcc所依赖的glibc都是主系统的glibc&＃xff0c;但对后面的编译并不造成影响。
那为什么要编译两次呢&＃xff1f;
CLFS2.0的工具链中第一遍只编译一个支持c的gcc&＃xff0c;原因是要编译出一个支持交叉的c&＃43;&＃43;&＃xff0c;必须有一个编译好的用于目标体系平台的glibc&＃xff0c;而不是只有glibc的头文件就可以的&＃xff0c;好在编译glibc有c支持就够了&＃xff0c;所以编译glibc也成了第一遍的gcc唯一的理由和作用。
在LFS中&＃xff0c;工具链里第二遍的gcc是由第一遍的gcc来完成编译的。
在CLFS2.0中&＃xff0c;我们知道第一遍编译的gcc就是交叉版本的gcc&＃xff0c;如果由它来编译第二次的gcc&＃xff0c;那么编译出来的就是目标体系平台的二进制文件&＃xff0c; 是无法在当前体系平台上运行的&＃xff0c;而我们还要用第二次编译的交叉版本的gcc来编译后面的内容&＃xff0c;所以绝对不能用第一遍的gcc来编译第二遍的gcc。
那么是谁来编译第二次的gcc呢&＃xff1f;
现在看这个问题应该是有点废话&＃xff0c;目前就只剩下主系统的gcc了&＃xff0c;也只有主系统的gcc现在能编译出在当前体系平台运行的交叉版本的gcc了。
现在明白了吧&＃xff0c;工具链中gcc的第一次和第二次编译都是由主系统的gcc和binutils来完成的&＃xff08;之前没有提及binutils&＃xff0c;只是为了理解方便&＃xff0c;但实际上编译后是少不了链接过程的&＃xff0c;这个过程是要binutils来完成的&＃xff09;。
到目前为止只有在编译glibc的时候用到了交叉版本的binutils&＃xff0c;其它部分的链接都是由主系统的binutils来完成的。
现在对工具链中gcc的两次编译的目的和原因差不多搞清楚了&＃xff0c;我们来看一下gcc两次编译参数的对比
第一次&＃xff1a;
../gcc-4.1.1/configure --prefix&＃61;${CLFS}/cross-tools \
--host&＃61;${CLFS_HOST} --target&＃61;${CLFS_TARGET} --disable-multilib \
--with-sysroot&＃61;${CLFS} --disable-nls --disable-shared \
--enable-languages&＃61;c
第二次&＃xff1a;
../gcc-4.1.1/configure --prefix&＃61;${CLFS}/cross-tools \
--host&＃61;${CLFS_HOST} --target&＃61;${CLFS_TARGET} --disable-multilib \
--with-sysroot&＃61;${CLFS} --disable-nls --enable-shared \
--enable-languages&＃61;c,c&＃43;&＃43; --enable-__cxa_atexit \
--enable-c99 --enable-long-long --enable-threads&＃61;posix
看来没什么特别需要说明的&＃xff0c;非交叉编译用的参数基本上和LFS没什么太大区别&＃xff0c;反正最重要的就是这个--with-sysroot&＃xff0c;好了&＃xff0c;三次--with-sysroot都出现了&＃xff0c;虽然前面对这个参数也说明了一下&＃xff0c;但不够详细&＃xff0c;下面我就来说说对这个关键参数的理解。
我们在做LFS的过程中了解到gcc在编译过程中是默认从/usr/include中找头文件的来编译的&＃xff0c;而binutils中的工具ld是从/lib /usr/lib、LD_LIBRARY_PATH、/etc/ld.so.conf等设置中所指定的路径搜索动态库或者静态库进行链接操作的&＃xff0c;而要改变这种默认情况则可以通过参数指定、打补丁等方式来达到目的&＃xff0c; 但是这样非常烦琐&＃xff0c;所以就产生了LFS中工具链的方法&＃xff0c;通过先做一个能自我编译的工具链&＃xff0c;但这些工具链中的程序都是连接到类似/tools/lib这样的 目录下的库中&＃xff0c;而且也是通过参数指定或者打补丁的方式来实现的&＃xff0c;并不符合标准的/lib /usr/lib&＃xff0c;所以后面在chroot后再用这个工具链来生成目标系统。
而现在我们用CLFS2.0的方法不需要再建立这个完整的工具链 了&＃xff0c;只是建立一个交叉用的工具链&＃xff0c;而这个工具链中的程序都是链接到/lib和/usr/lib里的库的&＃xff0c;这样一个工具链是不能chroot的&＃xff0c;但现在我们 要利用这个“不健全”的工具链来完成目标体系平台&＃xff0c;就必须要用到更改默认路径的方式&＃xff0c;这个方式就是--with-sysroot。
一个简单的理解就是&＃xff0c;默认的路径实际上都是{--with-sysroot}/usr {--with-sysroot}/usr/lib {--with-sysroot}/usr/include这样的形式&＃xff0c;只是在默认的情况下{--with-sysroot}表示的是空字符串&＃xff0c;这样就变成了/usr /usr/lib /usr/include&＃xff0c;而如果我们指定了--with-sysroot&＃xff0c;比如--with-sysroot&＃61;/mnt/clfs&＃xff0c;则默认路径就变成了/mnt/clfs/usr /mnt/clfs/usr/lib /mnt/clfs/usr/include&＃xff0c;这样我们在编译时查找头文件以及在链接时查找动态或静态库就自动到--with-sysroot指定的路径下来完成。这个就是--with-sysroot参数的目的。
这里需要注意的是&＃xff0c;--with-sysroot默认是只支持交叉编译的情况的&＃xff0c;我们可以从代码中印证&＃xff1a;
在gcc-core解压后的Makefile.in文件&＃xff08;你可以理解为是Makefile的一个模板文件&＃xff09;中有一段代码
# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR &＃61; /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR &＃61; &＃64;CROSS_SYSTEM_HEADER_DIR&＃64;
而对于CROSS_SYSTEM_HEADER_DIR的赋值在configure中有如下代码
CROSS_SYSTEM_HEADER_DIR&＃61;&＃39;$(TARGET_SYSTEM_ROOT)$(NATIVE_SYSTEM_HEADER_DIR)&＃39;
而同在configure中对TARGET_SYSTEM_ROOT的赋值
TARGET_SYSTEM_ROOT&＃61;$with_sysroot
现在明白了吧&＃xff0c;对于交叉方式&＃xff0c;是默认支持--with-sysroot的&＃xff0c;而普通的编译方式是不行的&＃xff0c;但也不是说我们就没办法了&＃xff0c;其实办法说起来也很简单&＃xff0c;就是改代码、打补丁。
我们来看三次使用--with-sysroot的作用和目的
第一次&＃xff0c;binutils下使用&＃xff0c;目的是让binutils在查找库的时候到--with-sysroot指定的地方查&＃xff0c;接着的glibc-headers和gcc都没有用到这个binutils&＃xff0c;我们先放一下&＃xff0c;看第二次使用&＃xff1b;
第二次&＃xff0c;第一次编译gcc下使用&＃xff0c;目的是让这个gcc在编译的时候默认到{--with-sysroot}/usr/include下找头文件。
接着我们就开始编译目标体系平台下的glibc了&＃xff0c;这个时候交叉版本的binutils和第一次编译的gcc都用上了&＃xff0c;则我们也就清楚了&＃xff0c;在编译这个 glibc的时候是到${CLFS}/usr/include里找头文件&＃xff0c;到${CLFS}/lib等目录下链接库的&＃xff0c;不过glibc是目标系统的第一个软件包&＃xff0c;因此&＃xff0c;它并不需要到${CLFS}/lib等目录下的库链接&＃xff0c;但交叉版本的binutils还是顺利的完成了glibc编译目录下自己众多库文件的链接工作。这里binutils的--with-sysroot没有体现出来&＃xff0c;但gcc的--with-sysroot已经发挥作用了。
第三次&＃xff0c;实际上这次是为了替换掉第一次编译的gcc而“重复”的&＃xff08;原因前面已经讲过了&＃xff09;&＃xff0c;所以可以理解和第二次使用--with-sysroot是一样的。
到现在为止&＃xff0c;gcc中的--with-sysroot已经体现出其作用了&＃xff0c;但binutils什么时候才能发挥作用呢&＃xff1f;
不要着急&＃xff0c;很快就到了它的用武之地了。
现在我们就完成了交叉工具链了……&＃xff08;画外音&＃xff1a;等等&＃xff0c;还有两个包没说呢&＃xff0c;怎么工具链就完成了&＃xff1f;&＃xff09;
这里我们先把--with-sysroot的问题放下&＃xff0c;现在出现了另外一个问题&＃xff0c;在LFS过程中我们知道工具链除了binutils和gcc外还有很多大量的工具包&＃xff0c;而在CLFS2.0中就只有file和groff两个包&＃xff0c;是什么意思呢&＃xff1f;
这里我们要全面了解工具链的作用以及这些工具包的作用&＃xff0c;在LFS中的工具链的目的不光是为了能编译&＃xff0c;而且是为了能够成为一个完整的自已自足的“系统”&＃xff0c; 再进入&＃xff08;chroot&＃xff09;这个“系统”后&＃xff0c;能够利用这种自已自足的能力创造新系统&＃xff0c;而这个过程中&＃xff0c;大量的工具包是少不了的&＃xff0c;这也就是为什么LFS的方法中需 要在工具链阶段里加入大量的工具包。
而在CLFS2.0之所以没有加入大量的包是因为&＃xff0c;CLFS2.0的方法里没有chroot这个环节&＃xff0c;所 以使用主系统的工具就可以了&＃xff0c;因此只需要gcc和binutils就可以完成任务了&＃xff0c;而file和groff其实我觉得也是没有必要的&＃xff0c;只要主系统中的 file和groff是符合要求的版本就可以了&＃xff0c;如果没有符合的版本编译一个也是可以的&＃xff0c;这里要注意的是file和groff是用主系统的gcc和binuitls完成编译链接的并依赖于主系统的glibc。
京公网安备 11010802041100号