内核研究 ：CLFS2.0原理分析

到目前为止只有在编译glibc的时候用到了交叉版本的binutils，其它部分的链接都是由主系统的binutils来完成的。
　　现在对工具链中gcc的两次编译的目的和原因差不多搞清楚了，我们来看一下gcc两次编译参数的对比
第一次：
../gcc-4.1.1/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --disable-multilib \
--with-sysroot=${CLFS} --disable-nls --disable-shared \
--enable-languages=c
第二次：
../gcc-4.1.1/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --disable-multilib \
--with-sysroot=${CLFS} --disable-nls --enable-shared \
--enable-languages=c,c++ --enable-__cxa_atexit \
--enable-c99 --enable-long-long --enable-threads=posix
　　看来没什么特别需要说明的，非交叉编译用的参数基本上和LFS没什么太大区别，反正最重要的就是这个--with-sysroot，好了，三次--with-sysroot都出现了，虽然前面对这个参数也说明了一下，但不够详细，下面我就来说说对这个关键参数的理解。
　　我们在做LFS的过程中了解到gcc在编译过程中是默认从/usr/include中找头文件的来编译的，而binutils中的工具ld是从 /lib /usr/lib、LD_LIBRARY_PATH、/etc/ld.so.conf等设置中所指定的路径搜索动态库或者静态库进行链接操作的，而要改变这种默认情况则可以通过参数指定、打补丁等方式来达到目的，但是这样非常烦琐，所以就产生了LFS中工具链的方法，通过先做一个能自我编译的工具链，但这些工具链中的程序都是连接到类似/tools/lib这样的目录下的库中，而且也是通过参数指定或者打补丁的方式来实现的，并不符合标准的/lib /usr/lib，所以后面在chroot后再用这个工具链来生成目标系统。

# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
 
中国网管论坛bbs.bitsCN.com
 

而对于CROSS_SYSTEM_HEADER_DIR的赋值在
configure中有如下代码
网管有家bitscn.net

CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$(NATIVE_SYSTEM_HEADER_DIR)'
 
网管联盟bitsCN@com
 

而同在configure中对TARGET_SYSTEM_ROOT的赋值
网管有家bitscn.net

TARGET_SYSTEM_ROOT=$with_sysroot
 
网管朋友网www_bitscn_net
 

　　现在明白了吧，对于交叉方式，是默认支持--with-sysroot的，而普通的编译方式是不行的，但也不是说我们就没办法了，其实办法说起来也很简单，就是改代码、打补丁。

　　我们来看三次使用--with-sysroot的作用和目的
　　第一次，binutils下使用，目的是让binutils在查找库的时候到--with-sysroot指定的地方查，接着的glibc-headers和gcc都没有用到这个binutils，我们先放一下，看第二次使用；
　　第二次，第一次编译gcc下使用，目的是让这个gcc在编译的时候默认到{--with-sysroot}/usr/include下找头文件。
　　接着我们就开始编译目标体系平台下的glibc了，这个时候交叉版本的binutils和第一次编译的gcc都用上了，则我们也就清楚了，在编译这个 glibc的时候是到${CLFS}/usr/include里找头文件，到${CLFS}/lib等目录下链接库的，不过glibc是目标系统的第一个软件包，因此，他并不需要到${CLFS}/lib等目录下的库链接，但交叉版本的binutils还是顺利的完成了glibc编译目录下自己众多库文件的链接工作。这里binutils的--with-sysroot没有体现出来，但gcc的--with-sysroot已经发挥作用了。
　　第三次，实际上这次是为了替换掉第一次编译的gcc而“重复”的（原因前面已经讲过了），所以可以理解和第二次使用--with-sysroot是一样的。 网管bitscn_com
　　到现在为止，gcc中的--with-sysroot已经体现出其作用了，但binutils什么时候才能发挥作用呢？
　　不要着急，很快就到了它的用武之地了。

　　现在我们就完成了交叉工具链了……（画外音：等等，还有两个包没说呢，怎么工具链就完成了？）
　　这里我们先把--with-sysroot的问题放下，现在出现了另外一个问题，在LFS过程中我们知道工具链除了binutils和gcc外还有很多大量的工具包，而在CLFS2.0中就只有file和groff两个包，是什么意思呢？
　　这里我们要全面了解工具链的作用以及这些工具包的作用，在LFS中的工具链的目的不光是为了能编译，而且是为了能够成为一个完整的自已自足的“系统”，再进入（chroot）这个“系统”后，能够利用这种自已自足的能力创造新系统，而这个过程中，大量的工具包是少不了的，这也就是为什么LFS的方法中需要在工具链阶段里加入大量的工具包。
　　而在CLFS2.0之所以没有加入大量的包是因为，CLFS2.0的方法里没有chroot这个环节，所以使用主系统的工具就可以了，因此只需要 gcc和binutils就可以完成任务了，而file和groff其实我觉得也是没有必要的，只要主系统中的file和groff是符合要求的版本就可以了，如果没有符合的版本编译一个也是可以的，这里要注意的是file和groff是用主系统的gcc和binuitls完成编译链接的并依赖于主系统的glibc。

网管bitscn_com

网管论坛bbs_bitsCN_com