［原创］CLFS2.0原理分析

更新日志
2006年9月28日：修改错字一处。
2006年8月30日：修改错误命令一处。
2006年8月22日：修改文字中的笔误两处。
2006年8月18日：修改图片中的笔误两处。

前言：
　　实际上，两三个星期前我第一次看CLFS2.0的时候有一种似曾相似的感觉，而且感觉看的非常顺，所以我只看到工具链完成后又看了两三个包的编译我就感觉想明白原理了，因为CLFS2.0的制作的方法我曾经自己尝试过，当时想研究出一种和LFS方法不同的方式来构建系统，虽然当时也做出来了一些成果，但感觉不成功（最重要的就是当时我不知道有--with-sysroot这个参数），但也有不少收获，而且我认为我当时的想法没有错，这可以在我以前的两篇文章《体积小巧、功能单一的LFS》和《LFS反向分析》中看到这个方法的影子，而后续包制作也和我在做憨牛包管理器中的打包方式方法类似，所以我感觉CLFS2.0方法不光适合用在交叉编译上，同样在非交叉的情况下也是适用的。
下面我就将我对CLFS2.0方法的理解总结一下，希望对CLFS感兴趣的朋友有所帮助，同时附加上我根据CLFS2.0的原理制作的PowerPC和MIPS的工具链部分，但因能力和理解力的限制，难免会有差错，也希望各位发现问题后能及时提出，以便及时更改，谢谢。


　　更新，由于篇幅比较长所以难免出现一些错误或者笔误，也有可能加入新内容，因此难免会进行修正或增删一些内容，如果本文被转载或者发现文章的更新日期已经比较久了，可能已经有更新，您可以在www.linuxsir.org的LFS版中或者在本人的Blog中查看最新版本。
　　linuxsir：http://www.linuxsir.org/bbs/showthread.php?t=267672
　　我的Blog：http://youbest.cublog.cn
　　如须转载请注明作者为冲天飞豹（youbest），并提供转载出处。

好的开始：
　　设置好环境变量对于后面的编译参数变的通用，也便于输入方便不容易出错
　　这里需要注意的是在
cat > ~/.bashrc << "EOF"
set +h
umask 022
CLFS=/mnt/clfs
LC_ALL=POSIX
PATH=${CLFS}/cross-tools/bin:/bin:/usr/bin
export CLFS LC_ALL PATH
EOF
里的PATH设置，这个PATH设置一直到制作结束也没有变化，这不同于LFS在第五章和第六章使用不同的PATH，这个问题之后在文章中会回答。

另一个重要设置就是
export CLFS_HOST="$(echo $MACHTYPE | sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")"
export CLFS_TARGET="arm-unknown-linux-gnu"
这个设置对于不同的体系平台会不一样，在文章的附录中有另外两个体系平台的定义。

　　一个说明：我们暂时把CLFS2.0中第五章的部分称为交叉工具链部分，而把第六章称为目标体系平台。

CLFS2.0中的绝招sysroot参数
　　sysroot参数一共出现了也就出现了三次，但这三次的使用可以说完全改变了以前的制作完整工具链的方法。
　　sysroot的目的其实很简单：就是将--with-sysroot所指定的目录作为根目录来使用。
　　我们会在文章中看到这三次sysroot是如何使用来达到目的的。


分析开始：
　　首先开始复制一些头文件到${CLFS}中的usr/include中，这个步骤似乎和以前没什么区别，但实际上我个人觉得这里少了一步，应该在复制前增加一句
　　接着我们就要安装binutils，这个包的目的就是为了连接目标文件为可执行文件，那么在第一次编译binutils的时候我们就要开始用--with-sysroot这个“神奇”的参数了。
../binutils-2.17/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-sysroot=${CLFS} \
--disable-nls --enable-shared --disable-multilib
　　从参数上的理解是，binutls将被安装到${CLFS}/cross-tools中（--prefix=${CLFS}/cross-tools），编译出来的二进制文件将运行在${CLFS_HOST}所指定的平台上（--host=${CLFS_HOST}），而其连接出的可执行文件是运行在${CLFS_TARGET}所指定的平台上（--target=${CLFS_TARGET}），屏蔽国际化支持（--disable-nls），同时编译出共享链接库（--enable-shared），不支持多种架构库（--disable-multilib），同时将${CLFS}所定义的目录作为根目录（--with-sysroot）
　　接着的make configure-host不要少了，这样可以利用前面设置的参数全面配置binutils所有需要编译的部分。
　　编译这个binutils是使用主系统的binutils和gcc来实现的，主系统是i386结构的，因此，这次我们编译出的这个binutils是利用主系统这个工具链来完成编译的，编译出来的程序也是运行在i386上的。

下面我们图解这个部分


　　由上图我们可以看出，实际上binutils编译过程中是没有用到目标体系的内核头文件的，因此复制内核的目标体系头文件和编译binutils的顺序是无所谓的。


　　接着我们就要准备开始编译GCC（不要以为我这里漏掉了glibc-2.4的headers这部分，这样安排正是为了说明glibc-2.4的headers部分为什么要在编译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将被安装到${CLFS}/cross-tools，而且只编译c语言部分，同时将${CLFS}所定义的目录作为根目录（--with-sysroot）
　　这里有必要解释一下一个比较重要的概念就是“交叉编译”，交叉编译简单的讲就是在一种体系的机器上编译出运行于另一种体系的代码（两种体系也可以是相同的，但通常是以不同的体系来说明），如下图：


　　这里很重要的一个部分就是编译器和链接器，这二者在这里对应的是GCC和binutils，它们即要运行于当前体系的系统下，又要能生成和处理目标体系的文件，因此称它们为交叉编译工具链。
　　这里比较重要的是GCC（并不是binutils不重要，只是我们重点要说明的是GCC），那么GCC是如何进行编译的呢？
　　这个问题要说清楚的话可以写一本书了，这里我只是从CLFS的角度来说明这个问题。GCC要编译出其它体系的代码，除了需要要编译的程序的源代码外还需要符合该体系的头文件，这里最重要的就是内核的头文件和glibc的头文件，所以作为交叉编译用的GCC，除了在编译其它程序的时候用到头文件，其自身也必须“了解”这些头文件，它必须掌握目标体系的全部细节，这已经由Linux的内核头文件给出了，另一点需要注意的是，GCC不仅可以用来在Linux下用，也可以用在其它支持的系统上，比如BSD，而C库也不局限于glibc，有可能是其它的C库，比如uclibc，所以要能够生成在目标体系的目标系统下运行的二进制代码，那么就必须对这一切都要了解，所以在编译GCC的时候必须有目标体系及目标系统相对应的头文件，这就解释了为什么要在编译GCC之前要先编译一个glibc-2.4的头文件部分。
　　下面来图解这段内容



　　现在我们回过头来，编译glibc-2.4符合目标系统的头文件，这部分我感觉也是各个体系差异比较大的部分，所以我们这里参考CLFS2.0第一个完成的体系ARM来说明（我只说重点，全部内容可以参考手册说明）
tar -jxvf ../glibc-ports-2.4.tar.bz2
mv -v glibc-ports-2.4 ports
这部分实际上是为了glibc能够支持arm而安装的，标准的glibc并不支持ARM等几个体系，而glibc-ports就是为了补充这部分的支持而出现的（这里必须将其改为ports，否则编译无法找到）。
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_arm_tls=yes" >> config.cache
这部分实际上是强制指定一些编译时候的参数，因为目前还没有交叉编译用的GCC，所以用主系统做./configure的时候有些参数会设置一些不正确的参数，因此这里强制声明是非常必要的，到工具链中第一遍的GCC完成后就可以正确设置这些参数了，所以再编译glibc就可以不用指定这些参数。
echo "install_root=${CLFS}" > configparms
这个就是为了指定安装目录，方便以后用make install直接装到${CLFS}目录下，其实不要这句也没问题，后面的make install改为make install_root=${CLFS} install-headers就可以了。
CC=gcc ../glibc-2.4/configure --prefix=/usr \
--host=${CLFS_TARGET} --build=${CLFS_HOST} \
--with-headers=${CLFS}/usr/include --cache-file=config.cache
这个编译参数说明gcc用的是主系统的gcc，这里需要注意的是--prefix=/usr虽然指定的是/usr目录，但实际上最后安装到的是${install_root}/usr下，如果没有指定install_root，那自然是安装到了/usr，而因为前面指定了install_root的目录，实际上最后安装到了${CLFS}/usr下，这里还需要注意的是--host和--build的指定（--host=${CLFS_TARGET} --build=${CLFS_HOST}），对比前面编译的binutils的参数（--host=${CLFS_HOST} --target=${CLFS_TARGET}），和后面GCC的参数（--host=${CLFS_HOST} --target=${CLFS_TARGET}），看到没有：

glibc-2.4　：--host=${CLFS_TARGET} --build=${CLFS_HOST}
binutils ：--host=${CLFS_HOST} --target=${CLFS_TARGET}
gcc 　：--host=${CLFS_HOST} --target=${CLFS_TARGET}

这里--host的指定刚好binutils和gcc相反，指定为目标体系，这点很重要，这是为了让后面即将编译的GCC能够准确的了解其要编译出的符合目标系统的二进制所需要的信息。
--with-headers指定了使用的头文件的目录，glibc唯一必须要的头文件就是内核的头文件，这点很有意义，因为glibc也是可以支持多种内核平台的，比如BSD，所以它也必须了解所服务的内核的所有特征细节，因此就不难理解为什么内核头文件必须先于glibc的头文件安装，只有这样glibc才能“了解”到准确的内核信息。
--cache-file则没什么好说的，就是让./configure对于--cache-file指定的文件中设置的参数强制使用。
make install-headers
到这里，我们还不需要一个完整的glibc，其实也无法进行编译的，因为目前的交叉编译用的GCC还没有，所以是无法编译的，但编译一个交叉编译的GCC又必须要一组C库的头文件，好在安装目标平台的glibc的头文件并不需要交叉编译器，所以这里直接安装头文件即可。
cp -v ../glibc-2.4/ports/sysdeps/unix/sysv/linux/arm/nptl/bits/pthreadtypes.h \
${CLFS}/usr/include/bits
这个是为了安装支持NPTL的头文件，这部分根据不同的平台复制的文件是不一样的，文章的附录中将介绍PowerPC和MIPS两种体系需要复制的文件，可作为参考。
（如果你前面没有仔细看，我提个醒，上面提到的glibc-headers部分和GCC第一次编译部分是反过来讲的，因此和书上没有冲突。）

　　好了，到目前为止已经有了一个交叉编译用的GCC和一个交叉链接用的binutils，以及一组目标平台和目标系统用的库文件，现在就可以正式的开始编译Linux平台的基础部分——C库(glibc)
　　在编译glibc的时候，同样指定了两个参数
　　echo "libc_cv_forced_unwind=yes" > config.cache
　　echo "libc_cv_c_cleanup=yes" >> config.cache
　　这两个参数于体系无关，而第三个参数
　　echo "libc_cv_arm_tls=yes" >> config.cache
　　则省略了，因为交叉编译环境已经完全了解你要编译的目标体系，所以可以自行检测出来。

　　这里着重需要明白的是glibc的编译参数
BUILD_CC="gcc" CC="${CLFS_TARGET}-gcc" \
AR="${CLFS_TARGET}-ar" RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.4/configure --prefix=/usr --libexecdir=/usr/lib/glibc \
--host=${CLFS_TARGET} --build=${CLFS_HOST} \
--disable-profile --enable-add-ons \
--with-tls --enable-kernel=2.6.0 --with-__thread \
--with-binutils=${CLFS}/cross-tools/bin --with-headers=${CLFS}/usr/include \
--cache-file=config.cache
　　BUILD_CC所指定的是用来建立在编译过程中需要运行的程序用什么gcc来编译，这个很重要，可以看出BUILD_CC指定的是主系统的gcc，主系统的gcc是一个运行于i386，编译出i386体系的编译器，因此它编译出来的程序可以在当前系统下运行，因为在编译过程中会编译一些临时使用的程序，而这些程序是编译完后就马上要用的，所以这些程序必须能在当前体系的平台上运行，因此必须以一个运行于当前体系平台，又编译出当前体系平台的编译器来完成，所以主系统的gcc自然成了最合适的选择。而CC所指定的是${CLFS_TARGET}-gcc，很明显是交叉编译用的GCC，原因很简单，最后编译出来的glibc的二进制库都是要在目标体系平台上运行的。AR和RANLIB是binutils中的工具，它们也是在编译过程中需要用到的，而且是用来处理目标平台的二进制文件，所以它们也是使用交叉编译用的版本。
　　--prefix和--libexecdir已经在前面编译glibc-headers部分说明过了，不要被表面现象所“迷惑”，最后安装到的是${install_root}/usr和${install_root}/usr/lib/glibc下。
　　--host指定也表明这里最后编译出来的库是用在目标体系平台下的。
　　--with-binutils则是为了表明在需要使用binutils的时候使用交叉版本所在的目录（这里不会影响BUILD_CC编译的临时程序，因为交叉版本在交叉工具链阶段是有前缀的）。
　　--with-headers和--cache-file解释同glibc-headers部分。
　　其余参数于LFS中含义相同，这里就不做解释了。
　　后面的make和make install自然没什么好说明的，只是这里因为前面设置了install_root的原因，在make install阶段会安装到install_root下。
　　下面按道理应该要安装locales了，但这里运行make localedata/install-locales并不能正确完成，原因很简单localedef是目标体系平台的程序，所以无法在本阶段完成，这里需要和前面说明的BUILD_CC编译的是可以在当前体系平台运行的临时程序分开看，因为localedef并不是一个临时用的文件，而是glibc的标准程序，所以这里也可以算是一个未解决的问题。我的建议是暂时跳过安装localedata部分。
　　在完成了glibc的编译和设置后，我们要进行第二次编译交叉版本的GCC了。
这里我想说明一下为什么要进行两次GCC编译的目的，这里和我们已经熟知的LFS中工具链里的两次GCC编译有着不同的原理。这一部分也算是CLFS2.0中的重点部分，我将以我的理解来说明这个问题：
　　在LFS里，工具链中第一遍编译gcc，是为了编译工具链中的glibc而编译的，而且为了能够保证编译器的正确则使用了make bootstrap来编译，在编译完glibc后，则再编译一遍gcc，目的是为了让这个gcc使用刚刚在工具链中编译好的glibc，为了是在后面完成工具链后chroot时保证工具链的可用，并且可以用来编译目标系统的glibc和LFS其他需要的软件。
　　而在CLFS2.0中，第一遍编译gcc,也确实为了编译glibc，而这个glibc却不是工具链中要用的，这是目标系统用的（这一点也可以通过第六章中没有编译glibc的部分来间接验证），并不是为了第二次编译gcc，让gcc链接到这个glibc用的，而且gcc也不能链接到这个glibc上，因为第一遍编译的交叉版本的gcc来编译出的glibc必然是目标体系平台的代码，所以在当前的体系平台上是运行不起来的，如果第二次编译的gcc链接到这个glibc上，那么这个gcc也就不能在当前的体系平台上运行了，所以CLFS2.0在工具链阶段的两次编译gcc，不是为了让gcc连接到新编译的glibc上。
　　那么究竟是什么原因呢？
　　我们先来看CLFS2.0第一编译GCC，没有使用make bootstrap来编译，而是使用make all-gcc来编译，也就是只编译了一次，这是合情合理的，要知道这个gcc是交叉版本，也就是说它再编译出来的是目标体系平台的二进制文件，虽然可以完成make bootstrap的第二步，但第三步是无法进行的，因为目标体系平台无法在当前平台上运行（make bootstrap，就是用第一遍编译的gcc来编译第二遍的gcc，再用第二遍的gcc编译第三遍的gcc，然后比较第二遍和第三遍的gcc，来确定编译是否正确），因此这里只需要也只能编译一遍。
　　在LFS里，第一遍gcc只编译了c语言部分，是因为编译glibc只需要c语言就行了，你当然也可以编译其它的语言支持，但没有什么意义，因为第一遍的gcc会被第二遍替换掉，而且第一遍是依赖于主系统glibc的，所以在chroot后就不能用了。
　　在CLFS2.0里没有chroot的过程，所以无论是工具链中的第一遍还是第二遍编译，gcc所依赖的glibc都是主系统的glibc，但对后面的编译并不造成影响。
　　那为什么要编译两次呢？
　　CLFS2.0的工具链中第一遍只编译一个支持c的gcc，原因是要编译出一个支持交叉的c++，必须有一个编译好的用于目标体系平台的glibc，而不是只有glibc的头文件就可以的，好在编译glibc有c支持就够了，所以编译glibc也成了第一遍的gcc唯一的理由和作用。
　　在LFS中，工具链里第二遍的gcc是由第一遍的gcc来完成编译的。
　　在CLFS2.0中，我们知道第一遍编译的gcc就是交叉版本的gcc，如果由它来编译第二次的gcc，那么编译出来的就是目标体系平台的二进制文件，是无法在当前体系平台上运行的，而我们还要用第二次编译的交叉版本的gcc来编译后面的内容，所以绝对不能用第一遍的gcc来编译第二遍的gcc。
　　那么是谁来编译第二次的gcc呢？
　　现在看这个问题应该是有点废话，目前就只剩下主系统的gcc了，也只有主系统的gcc现在能编译出在当前体系平台运行的交叉版本的gcc了。
　　现在明白了吧，工具链中gcc的第一次和第二次编译都是由主系统的gcc和binutils来完成的（之前没有提及binutils，只是为了理解方便，但实际上编译后是少不了链接过程的，这个过程是要binutils来完成的）。

　　到目前为止只有在编译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后再用这个工具链来生成目标系统。
　　而现在我们用CLFS2.0的方法不需要再建立这个完整的工具链了，只是建立一个交叉用的工具链，而这个工具链中的程序都是链接到/lib和/usr/lib里的库的，这样一个工具链是不能chroot，但现在我们要利用这个“不健全”的工具链来完成目标体系平台，就必须要用到更改默认路径的方式，这个方式就是--with-sysroot。
　　一个简单的理解就是，默认的路径实际上都是{--with-sysroot}/usr {--with-sysroot}/usr/lib {--with-sysroot}/usr/include这样的形式，只是在默认的情况下{--with-sysroot}表示的是空字符串，这样就变成了/usr /usr/lib /usr/include，而如果我们指定了--with-sysroot，比如--with-sysroot=/mnt/clfs，则默认路径就变成了/mnt/clfs/usr /mnt/clfs/usr/lib /mnt/clfs/usr/include，这样我们在编译时查找头文件以及在链接时查找动态或静态库就自动到--with-sysroot指定的路径下来完成。这个就是--with-sysroot参数的目的。
　　这里需要注意的是，--with-sysroot默认是只支持交叉编译的情况的，我们可以从代码中印证：
　　在gcc-core解压后的Makefile.in文件（你可以理解为是Makefile的一个摸板文件）中有一段代码
而对于CROSS_SYSTEM_HEADER_DIR的赋值在
configure中有如下代码
而同在configure中对TARGET_SYSTEM_ROOT的赋值
　　现在明白了吧，对于交叉方式，是默认支持--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是一样的。
　　到现在为止，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。

　　好了，下面我们就要开始编译目标系统的文件了。
　　之前我们已经在第五章的部分完成了glibc的编译，所以我们就可以直接编译各个包了，从CLFS2.0的手册来看，似乎还是遵循着LFS的先编译binutils和gcc，然后再编译其它的包，但这里又是和LFS的方法有着本质上的区别，下面我们就来对照一下看看。
　　在LFS中，我们在完成了工具链后，利用工具链来编译目标系统的glibc，之后是编译binutils，然后利用刚刚编译的binutils和工具链中的gcc来编译目标系统中的gcc，之后就利用刚刚编译的binutils和gcc来编译后面的部分，而之后每编译一个包，在后面的编译过程中需要用到这个包就是用刚刚编译好的，而不是工具链中的，直到把工具链中的所有包都替换成目标系统中的包，工具链就算完成目的了。比如在编译sed包之前，使用的是工具链中的sed命令，而当sed包编译完成之后，再用sed命令的时候，就是用刚刚编译好的目标系统中的sed命令了。
　　而在CLFS2.0中，我们知道现在用的是交叉版本的工具链，所以编译出来的是目标体系平台的代码，那么是不能在当前的体系平台下运行的，因此，也不会出现LFS中的替换过程，所以在CLFS2.0的方法中，还以sed命令为例，在交叉工具链编译目标体系平台的sed包前用的是主系统的sed命令，而编译完sed后，再用sed命令时，依然用的还是主系统的sed命令，因为刚刚编译的sed根本就不能在当前体系平台上运行。
　　现在我们就清楚了，我们也得出了几个结论：
　　1、第六章编译的包都是运行于目标体系平台的，所以不可以在当前体系平台上运行。
　　2、在CLFS2.0中第六章部分的binutils和gcc不是必须编译的，除非你需要在这个系统完成后移植到目标体系的机器中运行并要继续编译其它程序才需要编译binutils和gcc（这点和我以前写的《体积小巧、功能单一的LFS》思路是一样的）；
　　3、第六章的包编译顺序是不需要这么严格的，特别是只有命令的包，是可以随便摆放顺序的，比如coreutils这个包，在手册中是位于gcc之后就编译了，但实际上即使放在最后一个包编译也没问题，因为这个包编译出来的命令根本就在这里用不上，部分命令如果觉得在目标系统中根本不用，即使不编译都可以，比如你不打算在目标体系平台中用patch命令，你就可以不安装这个命令，这是不会影响编译效果的。
　　4、不是所有的包都可以随意改变编译顺序的，对于有动态或者静态库的文件，如果有其它的包需要，那么就必须先于依赖于它的包编译，比如ncurses和readline，因为readline要链接ncurses的库，所以ncurses必须比readline先编译，否则会导致编译问题。
　　5、在整个第六章的过程中都是由主系统中的工具包和交叉编译工具链来完成编译的，这个时候binutils和gcc的--with-sysroot发挥着重要的作用（binutils中的--with-sysroot终于开始用上了），因为这个参数，使得整个第六章的编译过程在没有路径补丁的情况下变的相对“顺利”起来。

关于系统的“纯净度”
　　说到这里不得不提我对这里编译过程中使用主系统的工具包来完成编译的看法，就是系统“纯净度”的问题，在LFS的方法中，利用独立的工具链来生成目标系统以保证和原系统“不相干”，而这里没有这样一个完整的工具链是否会影响它的“纯净度”呢？
　　我的回答是：不影响任何“纯净度”。
　　原因很简单，对纯净度的影响最主要的就是编译过程中对原系统中库的依赖，但实际上我们知道交叉编译的目的就是为了编译出运行于其它体系平台的代码，如果编译出的代码和原系统还有关系的话，这个结果就是完全失败的东西，因为有部分代码无法在目标体系平台中运行，这是非常失败的。在CLFS2.0中交叉编译用的binutils和gcc都新编译出来的，不是主系统的，因此这方面没什么问题（实际上即使主系统提供了交叉编译的工具，也没有问题。），接着就是这些主系统提供的工具包是否会带来“纯净度”的问题，我的一个观点就是这些工具只是处理诸如文本之类的于平台无关的文件，所以只要能够正确处理这类文件，就没问题，这是完全跟“纯净度”无关的因素。当然如果主系统提供的命令不适合或者版本太低，则需要象前面的提到的file和groff的方式一样——编译一个。

　　好了，在讲完第六章的的几个结论后，再来谈谈第六章编译的包的安装问题，对编译过程比较清楚的朋友基本上都了解一般软件包的编译过程
./configure 若干参数
make
make install
　　前两个命令没什么问题，最后一个make install，一般会将其安装到--prefix指定的目录中，而一般我们在参数中都是用--prefix=/usr这样的，这个参数是很重要的，有些包在运行过程中都可能受这个参数的影响，那么我们现在要安装到${CLFS}才行，如果用这样的--prefix=/usr参数，又用make install来安装的话，但愿你不是用root来执行的，否则你的系统就要被破坏了。这里正确的方法是用DESTDIR来指定“根”目录，如make DESTDIR=${CLFS} install，这很类似前面说明的--with-sysroot的概念，这里就不多说了，我在做憨牛包管理器的时候就用到了这个方法，很实用，但不是所有的包都支持，但大多数标准的gun包是支持的，可参考各个包的说明，也可以查看代码来确定。

　　最后要说的就是关于目标系统如何启动了，在发稿时为止CLFS2.0还是开发中的版本，而它目前也只有arm和x86两中体系，x86我们知道可以用grub来做启动，而arm却没有提到，各种体系都有各自的启动系统，可以参考CLFS1.0中的相应部分。

　　最后我们来尝试画一个CLFS2.0的逻辑图（图中未表达出--with-sysroot的作用，但不影响表达CLFS2.0的方法）。

　　如果观察仔细的话会发现这副图里没有提到任何Linux的字样，因为我觉得这样的方法是适合其它类似的开源系统的，比如BSD。

（转载请保持文章的完整性，请注明作者和出处）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：冲天飞豹（youbest）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Email:[email protected]
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2006年8月12日


附录：
PowerPC的工具链制作过程及内核编译
环境设置过程（略）
export CLFS_HOST="$(echo $MACHTYPE | sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")"
export CLFS_TARGET="powerpc-unknown-linux-gnu"
echo export CLFS_HOST=\""${CLFS_HOST}\"" >> ~/.bashrc
echo export CLFS_TARGET=\""${CLFS_TARGET}\"" >> ~/.bashrc

Linux-Kernel-headers
make include/linux/version.h
install -dv ${CLFS}/usr/include/{asm,asm-generic,linux,net,mtd,scsi,sound}
cp -av include/asm-generic/* ${CLFS}/usr/include/asm-generic
cp -av include/linux/* ${CLFS}/usr/include/linux
cp -av include/mtd/* ${CLFS}/usr/include/mtd
cp -av include/net/* ${CLFS}/usr/include/net
cp -av include/scsi/* ${CLFS}/usr/include/scsi
cp -av include/sound/* ${CLFS}/usr/include/sound
install -dv ${CLFS}/usr/include/asm-ppc
cp -av include/asm-powerpc/* ${CLFS}/usr/include/asm
cp -av include/asm-ppc/* ${CLFS}/usr/include/asm-ppc

binutils-2.17
patch -Np1 -i ../binutils-2.17-posix-1.patch
mkdir -v ../binutils-build
cd ../binutils-build
../binutils-2.17/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-sysroot=${CLFS} \
--disable-nls --enable-shared --disable-multilib
make configure-host
make
make install
cp -v ../binutils-2.17/include/libiberty.h ${CLFS}/usr/include

glibc-2.4-headers
cp configure{,.orig}
sed -e 's/3.4/3.[0-9]/g' configure.orig > configure
mkdir -v ../glibc-build
cd ../glibc-build
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_powerpc32_tls=yes" >> config.cache
echo "libc_cv_ppc_machine=yes" > config.cache
echo "libc_cv_mlong_double_128=yes" >> config.cache
echo "libc_cv_mlong_double_128ibm=yes" >> config.cache
echo "install_root=${CLFS}" > configparms
CC=gcc ../glibc-2.4/configure --prefix=/usr \
--host=${CLFS_TARGET} --build=${CLFS_HOST} \
--with-headers=${CLFS}/usr/include --cache-file=config.cache
make install-headers
install -dv ${CLFS}/usr/include/bits
cp -v bits/stdio_lim.h ${CLFS}/usr/include/bits
touch ${CLFS}/usr/include/gnu/stubs.h
cp -v ../glibc-2.4/nptl/sysdeps/unix/sysv/linux/powerpc/bits/pthreadtypes.h \
${CLFS}/usr/include/bits

gcc-4.1.1第一遍
patch -Np1 -i ../gcc-4.1.1-posix-1.patch
patch -Np1 -i ../gcc-4.1.1-cross_search_paths-1.patch
mkdir -v ../gcc-build
cd ../gcc-build
../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
make all-gcc
make install-gcc

glibc-2.4
patch -Np1 -i ../glibc-2.4-libgcc_eh-1.patch
patch -Np1 -i ../glibc-2.4-localedef_segfault-1.patch
patch -Np1 -i ../glibc-2.4-crosscompile_timezone_fix-1.patch
patch -Np1 -i ../glibc-2.4-iconv_fix-1.patch
mkdir -v ../glibc-build
cd ../glibc-build
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "install_root=${CLFS}" > configparms
BUILD_CC="gcc" CC="${CLFS_TARGET}-gcc" \
AR="${CLFS_TARGET}-ar" RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.4/configure --prefix=/usr --libexecdir=/usr/lib/glibc \
--host=${CLFS_TARGET} --build=${CLFS_HOST} \
--disable-profile --enable-add-ons \
--with-tls --enable-kernel=2.6.0 --with-__thread \
--with-binutils=${CLFS}/cross-tools/bin --with-headers=${CLFS}/usr/include \
--cache-file=config.cache
make
make install
cat > ${CLFS}/etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf
passwd: files
group: files
shadow: files
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
# End /etc/nsswitch.conf
EOF
TZDIR="${CLFS}/usr/share/zoneinfo" ${CLFS}/usr/bin/tzselect
cp -v --remove-destination ${CLFS}/usr/share/zoneinfo/[xxx] \
${CLFS}/etc/localtime
cat > ${CLFS}/etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib
# End /etc/ld.so.conf
EOF

gcc-4.1.1第二遍
patch -Np1 -i ../gcc-4.1.1-posix-1.patch
patch -Np1 -i ../gcc-4.1.1-PR20425-1.patch
patch -Np1 -i ../gcc-4.1.1-cross_search_paths-1.patch
mkdir -v ../gcc-build
cd ../gcc-build
../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
make
make install

file-4.17
./configure --prefix=${CLFS}/cross-tools
make
make install

Groff-1.19.2
PAGE=A4 ./configure --prefix=${CLFS}/cross-tools --without-x
make
make install

工具链制作完成
目标系统制作
export CC="${CLFS_TARGET}-gcc"
export CXX="${CLFS_TARGET}-g++"
export AR="${CLFS_TARGET}-ar"
export AS="${CLFS_TARGET}-as"
export RANLIB="${CLFS_TARGET}-ranlib"
export LD="${CLFS_TARGET}-ld"
export STRIP="${CLFS_TARGET}-strip"
echo export CC=\""${CC}\"" >> ~/.bashrc
echo export CXX=\""${CXX}\"" >> ~/.bashrc
echo export AR=\""${AR}\"" >> ~/.bashrc
echo export AS=\""${AS}\"" >> ~/.bashrc
echo export RANLIB=\""${RANLIB}\"" >> ~/.bashrc
echo export LD=\""${LD}\"" >> ~/.bashrc
echo export STRIP=\""${STRIP}\"" >> ~/.bashrc

Linux-2.6.17.6
make ARCH=powerpc CROSS_COMPILE=${CLFS_TARGET}- menuconfig
make ARCH=powerpc CROSS_COMPILE=${CLFS_TARGET}-
make ARCH=powerpc CROSS_COMPILE=${CLFS_TARGET}- \
INSTALL_MOD_PATH=${CLFS} modules_install
cp vmlinux ${CLFS}/boot/clfskernel-2.6.17.6
cp System.map ${CLFS}/boot/System.map-2.6.17.6
cp .config ${CLFS}/boot/config-2.6.17.6


MIPS的工具链制作过程及内核编译
环境设置过程（略）
export CLFS_HOST="$(echo $MACHTYPE | sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")"
export CLFS_TARGET="mips-unknown-linux-gnu"
echo export CLFS_HOST=\""${CLFS_HOST}\"" >> ~/.bashrc
echo export CLFS_TARGET=\""${CLFS_TARGET}\"" >> ~/.bashrc

Linux-Kernel-headers
make include/linux/version.h
install -dv ${CLFS}/usr/include/{asm,asm-generic,linux,net,mtd,scsi,sound}
cp -av include/asm-generic/* ${CLFS}/usr/include/asm-generic
cp -av include/linux/* ${CLFS}/usr/include/linux
cp -av include/mtd/* ${CLFS}/usr/include/mtd
cp -av include/net/* ${CLFS}/usr/include/net
cp -av include/scsi/* ${CLFS}/usr/include/scsi
cp -av include/sound/* ${CLFS}/usr/include/sound
cp -av include/asm-mips/* ${CLFS}/usr/include/asm

binutils-2.17
patch -Np1 -i ../binutils-2.17-posix-1.patch
mkdir -v ../binutils-build
cd ../binutils-build
../binutils-2.17/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-sysroot=${CLFS} \
--disable-nls --enable-shared --disable-multilib
make configure-host
make
make install
cp -v ../binutils-2.17/include/libiberty.h ${CLFS}/usr/include


glibc-2.4-headers
cp configure{,.orig}
sed -e 's/3.4/3.[0-9]/g' configure.orig > configure
tar -jxvf ../glibc-ports-2.4.tar.bz2
mv -v glibc-ports-2.4 ports
echo "" > ports/sysdeps/mips/mips32/Makefile
sed -i ‘s/wordsize.h>$/wordsize.h>\n#define __WORDSIZE 32/g’ bits/types.h
mkdir -v ../glibc-build
cd ../glibc-build
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "libc_cv_mips_tls=yes" >> config.cache
echo "install_root=${CLFS}" > configparms
CC=gcc ../glibc-2.4/configure --prefix=/usr \
--host=${CLFS_TARGET} --build=${CLFS_HOST} \
--with-headers=${CLFS}/usr/include --cache-file=config.cache
make install-headers
install -dv ${CLFS}/usr/include/bits
cp -v bits/stdio_lim.h ${CLFS}/usr/include/bits
touch ${CLFS}/usr/include/gnu/stubs.h
cp -v ../glibc-2.4/ports/sysdeps/unix/sysv/linux/mips/nptl/bits/pthreadtypes.h \
${CLFS}/usr/include/bits

gcc-4.1.1第一遍
patch -Np1 -i ../gcc-4.1.1-posix-1.patch
patch -Np1 -i ../gcc-4.1.1-cross_search_paths-1.patch
mkdir -v ../gcc-build
cd ../gcc-build
../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
make all-gcc
make install-gcc

glibc-2.4
patch -Np1 -i ../glibc-2.4-libgcc_eh-1.patch
patch -Np1 -i ../glibc-2.4-localedef_segfault-1.patch
patch -Np1 -i ../glibc-2.4-crosscompile_timezone_fix-1.patch
patch -Np1 -i ../glibc-2.4-iconv_fix-1.patch
ln -s nptl/sysdeps/unix/sysv/linux/i386 ports/sysdeps/unix/
mkdir -v ../glibc-build
cd ../glibc-build
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
echo "install_root=${CLFS}" > configparms
BUILD_CC="gcc" CC="${CLFS_TARGET}-gcc" \
AR="${CLFS_TARGET}-ar" RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.4/configure --prefix=/usr --libexecdir=/usr/lib/glibc \
--host=${CLFS_TARGET} --build=${CLFS_HOST} \
--disable-profile --enable-add-ons \
--with-tls --enable-kernel=2.6.0 --with-__thread \
--with-binutils=${CLFS}/cross-tools/bin --with-headers=${CLFS}/usr/include \
--cache-file=config.cache
make
make install

cat > ${CLFS}/etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf
passwd: files
group: files
shadow: files
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
# End /etc/nsswitch.conf
EOF
TZDIR="${CLFS}/usr/share/zoneinfo" ${CLFS}/usr/bin/tzselect
cp -v --remove-destination ${CLFS}/usr/share/zoneinfo/[xxx] \
${CLFS}/etc/localtime
cat > ${CLFS}/etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib
# End /etc/ld.so.conf
EOF

gcc-4.1.1第二遍
patch -Np1 -i ../gcc-4.1.1-posix-1.patch
patch -Np1 -i ../gcc-4.1.1-PR20425-1.patch
patch -Np1 -i ../gcc-4.1.1-cross_search_paths-1.patch
mkdir -v ../gcc-build
cd ../gcc-build
../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
make
make install

file-4.17
./configure --prefix=${CLFS}/cross-tools
make
make install

Groff-1.19.2
PAGE=A4 ./configure --prefix=${CLFS}/cross-tools --without-x
make
make install

工具链制作完成
目标系统制作
export CC="${CLFS_TARGET}-gcc"
export CXX="${CLFS_TARGET}-g++"
export AR="${CLFS_TARGET}-ar"
export AS="${CLFS_TARGET}-as"
export RANLIB="${CLFS_TARGET}-ranlib"
export LD="${CLFS_TARGET}-ld"
export STRIP="${CLFS_TARGET}-strip"
echo export CC=\""${CC}\"" >> ~/.bashrc
echo export CXX=\""${CXX}\"" >> ~/.bashrc
echo export AR=\""${AR}\"" >> ~/.bashrc
echo export AS=\""${AS}\"" >> ~/.bashrc
echo export RANLIB=\""${RANLIB}\"" >> ~/.bashrc
echo export LD=\""${LD}\"" >> ~/.bashrc
echo export STRIP=\""${STRIP}\"" >> ~/.bashrc

Linux-2.6.17.6
cp arch/mips/configs/qemu_defconfig .config
make ARCH=mips CROSS_COMPILE=${CLFS_TARGET}- menuconfig
make ARCH=mips CROSS_COMPILE=${CLFS_TARGET}-
make ARCH=mips CROSS_COMPILE=${CLFS_TARGET}- \
INSTALL_MOD_PATH=${CLFS} modules_install
cp vmlinux ${CLFS}/boot/clfskernel-2.6.17.6
cp System.map ${CLFS}/boot/System.map-2.6.17.6
cp .config ${CLFS}/boot/config-2.6.17.6

（转载请保持文章的完整性，请注明作者和出处）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：冲天飞豹（youbest）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Email:[email protected]
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2006年8月12日

更新日志：
2006年8月18日：
修改了图片中的笔误两处，将MIPS写成了IMPS，已更正。
由cublog上的ｆｌｗ１００００报告。

2006年8月22日：
修改了文字中的笔误两处，将MIPS写成了IMPS，已更正。

2006年8月30日：
修改错误命令
cp -av include/asm-mips/* /usr/include/asm
为
cp -av include/asm-mips/* ${CLFS}/usr/include/asm
由cublog上的flw10000发现并报告

2006年9月28日：
修改错字一处
“有这不同的原理”修正为“有着不同的原理”
由cublog上的bee_slayer发现并报告

顶，youbest 好文。

我的理解，就是完全的 Cross－Compile 了？

还在我理解范围之外.........

又想起那句经典：youbest的帖子就是精华贴的代名词！
先顶了再看！

偶的专利，，哼哼，，，：）。。。

终于见到了大作了，太好了。。。仔细看看先。。。。

先顶～

然后慢慢学习～

吓死了

我小菜鸟还不知道cross的意义

又見 youbest 大作，吾自愧不如，學習學習。。。
堅決打倒一切無理的 patent！。。。

我很羡慕d00m3d对Linux系统知识的广泛，俺找工作现在就怕人家问在Linux如何用某个工具做一件什么事情，用什么命令或者工具可以完成某个任务什么的，保证是一问三不知。
要向d00m3d学习，问什么基本都能回答个一二三来，这才叫精通呢，吾自愧不如，學習學習。。。

youbest 太歉虚及过於抬举在下了，论精通系统，小弟远不及幻想老大呢

让我们一起学习学习吧。。。：）

仔细读了两次，文章写的很详细。：）。

仔细研究后，偶觉得偶不太喜欢 CLFS2 的方式，全部都是 Cross 编译的。不过也算是一个创新，没准以后会向这方面发展的说（以后是什么概念？）。毕竟native（本地？）编译才是一般软件支持的方式，跨平台了，很多细节要处理。麻烦多多。活活。。。

学习学习CLFS2，偶还是喜欢CLFS1的方法。实在。。：）。

向楼上的2位高人学习！。。

本人系统：
uname -a
Linux woaiwojia 2.6.15-26-amd64-k8 #1 SMP PREEMPT Thu Aug 3 03:11:38 UTC 2006 x86_64 GNU/Linux

gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保；
包括没有适销性和适用性担保。

小弟是菜鸟，按照CLFS2.0 ARM进行操作，前面都顺利，操作到 5.6. Glibc-2.4 Headers时出错，错误如下：
..........................
nptl/sysdeps/pthread/Subdirs sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs assert/Depend intl/Depend catgets/Depend stdlib/Depend stdio-common/Depend libio/Depend malloc/Depend string/Depend wcsmbs/Depend time/Depend posix/Depend iconvdata/Depend nss/Depend localedata/Depend rt/Depend debug/Depend > /mnt/clfs/glibc-build/sysd-sorted-tmp
mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed (bad class -- [], [^] or [)/[^
mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ]
mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, "", subd ...
make[1]: Leaving directory `/mnt/clfs/glibc-2.4'
make[1]: Entering directory `/mnt/clfs/glibc-2.4'
{ echo '#include "posix/bits/posix1_lim.h"'; \
echo '#define _LIBC 1'; \
echo '#include "misc/sys/uio.h"'; } | \
gcc -E -dM -MD -MP -MF /mnt/clfs/glibc-build/bits/stdio_lim.dT -MT '/mnt/clfs/glibc-build/bits/stdio_lim.h /mnt/clfs/glibc-build/bits/stdio_lim.d' \
........................................................
nptl/sysdeps/pthread/Subdirs sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs assert/Depend intl/Depend catgets/Depend stdlib/Depend stdio-common/Depend libio/Depend malloc/Depend string/Depend wcsmbs/Depend time/Depend posix/Depend iconvdata/Depend nss/Depend localedata/Depend rt/Depend debug/Depend > /mnt/clfs/glibc-build/sysd-sorted-tmp
mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed (bad class -- [], [^] or [)/[^
mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ]
mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, "", subd ...
/usr/bin/install -c -m 644 include/limits.h /mnt/clfs/usr/include/limits.h
/usr/bin/install -c -m 644 include/values.h /mnt/clfs/usr/include/values.h
/usr/bin/install -c -m 644 include/features.h /mnt/clfs/usr/include/features.h
/usr/bin/install -c -m 644 include/gnu-versions.h /mnt/clfs/usr/include/gnu-versions.h
/usr/bin/install -c -m 644 nptl/sysdeps/pthread/bits/libc-lock.h /mnt/clfs/usr/include/bits/libc-lock.h
/usr/bin/install -c -m 644 include/bits/xopen_lim.h /mnt/clfs/usr/include/bits/xopen_lim.h
/usr/bin/install -c -m 644 include/gnu/libc-version.h /mnt/clfs/usr/include/gnu/libc-version.h
/usr/bin/install -c -m 644 /mnt/clfs/glibc-build/gnu/lib-names.h /mnt/clfs/usr/include/gnu/lib-names.h
/usr/bin/install: cannot stat `/mnt/clfs/glibc-build/gnu/lib-names.h': No such file or directory
make[1]: *** [/mnt/clfs/usr/include/gnu/lib-names.h] Error 1
make[1]: Leaving directory `/mnt/clfs/glibc-2.4'
make: *** [install-headers] Error 2

为了避免不必要的麻烦，小弟是完全按照CLFS 2.0 ARM一步一步操作的，至此出了这个错误，小弟找遍FAQ 和 mailing list也没有找到答案，还请各位大侠帮忙啊！！！！！！！！

我没用过Ubuntu，不太清楚Ubuntu的一些环境，但感觉可能是mawk导致的问题，LFS中是使用Gawk的，两者可能有些区别。

如 youbest 所说，装 gawk。。

感谢楼上的两位大侠，正如youbest楼主所说，是mawk的问题，换装gawk就ok了！俺本来是要作一个嵌入式系统的交叉编译环境，参考书是《Building Embedded Linux Systems》结果折腾了快10天了不行，俺就搜资料搜的了这个贴，真是太感谢了！现在俺继续往下进行，但愿一切顺利！

问题已经解决了，果然是 mawk的问题，换成gawk就好了，两位大侠果然是高手！整个交叉编译环境都搞定了，再次感谢！

各位大侠，小菜鸟我根据youbest楼主的帖子顺利的作出了交叉编译环境，但是我最终的目的是生成一个潜入式的交叉编译环境，所以用glibc是太大了，youbest楼主的文章中提到了uClibc，能否给我推荐一个合适的版本啊，先谢谢了！

修改错误命令一处

去uClibc的网站下个最新的试试看吧.

谢谢楼主的答复

据飞豹侠的分析，clfs2中第一遍交叉版gcc的生成必须要有交叉用glibc头文件的预先安装
为何clfs1中同样的第一遍交叉版gcc就不需要这个glibc头文件？

以前一直都需要的，后来在 x86几个体系上，就忽略了。看起来是不需要。也许是 gcc-static 自带了头文件吧。

终于等到幻想老大回复了，多谢！
噢，以前一直都需要的啊，我学的是rc4，此时不需要了
那不知道在clfs2中的x86版不知道可不可以也不需要啊，得实践了

看来我的linux道路还是任重而道远地:-(

export CLFS_TARGET="powerpc-unknown-linux-gnu"

在binultils编译中
make configure-host出错

checking target system type... Invaid configuration '{CLFS_TARGET}' : machine '{CLFS_TARGET}' not recognized
configure:error: /bin/sh ../..binutils-2.17/bfd/../config.sub {CLFS_TARGET} failed
make: ***[configure-bfd] Error 1

你在配binutils的configure的时候用的{CLFS_TARGET}而不是${CLFS_TARGET}??

你在配binutils的configure的时候用的{CLFS_TARGET}而不是${CLFS_TARGET}??

发现了。。。真不好意思。。。拿这种问题来麻烦你。。。。

没关系，大家都是这样一步一步走过来的，有问题尽管提 ，不过LFS细心确实很重要。

拷贝 headers 的时候，你把 ppc 和 powerpc 都拷贝过去了。
我看 CLFS1 的确是这么做的 ，那是不是就是说 powerpc 需要 ppc header，换句话就是说 powerpc 是 ppc体系的一种？


http://cross-lfs.org/view/clfs-sysro...ols/glibc.html 里边显示， localedef 似乎搞定了，多弄了一个本地的 localedef-native。。忽忽。

理解起来有点吃力. 还是多读几遍.
(我认为需要多读几遍才能领会的东西肯定是好东西).
谢谢lz!!

为arm编译clf2.0刚完成了5.7 Cross GCC-4.1.2 - Static .过程中遇到的几个问题说一下
我的主机是lfs, gcc是3.2,编译glibc头的时候不能通过,因为gcc到3.4才支持线程局部变量__thread.于是装了gcc3.4.6,通过.
编译binutil-2.17,开始按手册用了--enable-shared,到编译gcc时动态库出问题,可能因为此时还未编译glibc,没有ld.so.于是去掉此选项,可以了.
用--with-build-sysroot而不是--with-sysroot.congfiguer --help只有前面一个选项.
实际上开始用后一个选项时路径不正确,说明未起作用.(疑问如果有这两个选项,它们的区别是什么?)
最后在编译gcc时把${clfs}/usr/include目录拷到${clfs}/cross-tools/arm-unkwon-inux-gnu/下,因为gcc的isysroot选项是在这个目录里找头文件的.

为arm编译clf2.0刚完成了5.7 Cross GCC-4.1.2 - Static .过程中遇到的几个问题说一下
我的主机是lfs, gcc是3.2,编译glibc头的时候不能通过,因为gcc到3.4才支持线程局部变量__thread.于是装了gcc3.4.6,通过.
编译binutil-2.17,开始按手册用了--enable-shared,到编译gcc时动态库出问题,可能因为此时还未编译glibc,没有ld.so.于是去掉此选项,可以了.
用--with-build-sysroot而不是--with-sysroot.congfiguer --help只有前面一个选项.
实际上开始用后一个选项时路径不正确,说明未起作用.(疑问如果有这两个选项,它们的区别是什么?)
最后在编译gcc时把${clfs}/usr/include目录拷到${clfs}/cross-tools/arm-unkwon-inux-gnu/下,因为gcc的isysroot选项是在这个目录里找头文件的.

我昨天倒是一路很顺利的做了下来，没出什么错误。你严格按照书上来的？
我的主系统是 ARCH x86，更新到最新的。

glibc对arm来说，显得大了一点，我在用clfs3.0的指导，用uClibc和busybox编arm平台的，但好像挺困难的。回头试一下glibc。
另外，gcc第一次编译的时候，应该disable-shared,书上好像说到过。

我也许回答错了问题，我做的是 sysroot 的，不是 embedded。

有一点搂主还是说得不是很清楚，就是为什么gcc要编译两次。
如果第一次出来的cross gcc 只是为了编译glibc的话，那他应该也可以编译其他的软件包，即使不行，我们第一次就添加c++的功能，总行了吧，为什么还要编译两次？难道说第一次只能编译出一个只支持c的gcc ?

这是我的疑问，望各位兄弟不吝赐教，小弟不胜感激.

同问ing....

第一次：--disable-shared
第二次：--enable-shared

you can not disble and enalbe at once? but why disable 1st then enable 2nd?

刚在LFS论坛里发了个帖子问大伙为什么CLFS1.0.0手册里制作的临时系统不能直接作为目标板最后的系统就看到了这篇大作。楼主分析的很详细啊，我没看过CLFS2.0，不过根据这个帖子，感觉没什么区别啊。
引用原文：
那么在第一次编译binutils的时候我们就要开始用--with-sysroot这个“神奇”的参数了。
../binutils-2.17/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-sysroot=${CLFS} \
--disable-nls --enable-shared --disable-multilib

对照CLFS1.0.0
../binutils-2.17/configure --prefix=/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-lib-path=/tools/lib \
--disable-nls --enable-shared --disable-multilib
仅仅是把--with-lib-path=/tools/lib换作 --with-sysroot=${CLFS}
引用原文：
../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
对照CLFS1.0.0
../gcc-4.1.1/configure --prefix=/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --disable-multilib \
--with-local-prefix=/tools --disable-nls --disable-shared \
--disable-threads --enable-languages=c
同样，仅仅是将--with-local-prefix=/tools换作--with-sysroot=${CLFS}

如楼主所说，--with-sysroot第三次出现跟第二次的道理一样，不比较了。
--with-sysroot无非也就是指定了一下头文件和库的路径，与CLFS1.0.0并无实质改变，
但是CLFS1.0.0里这条交叉链下线的系统就被用作了一个临时系统，还特意给了个warning：Warning
Here a temporary cross-compiled kernel will be built. When configuring it, select the minimal amount of options required to boot the target machine and build the final system. I.e., no support for sound, printers, etc. will be needed.

Also, try to avoid the use of modules if possible, and don't use the resulting kernel image for production systems.
说这个内核不能作为最终的内核？为什么到了CLFS2.0就可以了呢，不明白。

老大的这几句话还有些地方需要探讨。

如果说编译出的 glibc 没有用到第 2 次 gcc 的编译过程中，那么编译 glibc 和第 2 次 gcc 完全可以不分先后，但实际上是有先后的，所以它这样安排肯定有道理的。

我在实际编译的过程中，在编译出 glibc 以后，第 2 次编译 gcc 的时候，曾经出错提示是找不到相关的一些库，而我把生成的 glibc 目录下的 libc.so 文件修改后，第 2 次的 gcc 编译就过了，这说明第 2 次的 gcc 编译还是需要使用编译出的 glibc 的。

所以我的理解是这样的：

第 2 次编译 gcc 需要用到 glibc，但并不是说编译 gcc 的时候链接 glibc 的库，而是用它来完成一些设置或者是其它作用，因为如果链接了编译出的 glibc，那么它就无法在主机上运行，但缺了它又无法编译 gcc，所以才觉得要用，但用在哪儿现在还不是特别的清楚。

请老大们关注一下，这部分一直都是存在争议，现在想弄个定论出来。

ls 你有必要搞清楚什么是CLFS2.0，什么是CLFS-Sysroot，什么是交叉编译工具链。
简单的说，你错大发了。
这部分没有争议，只有误解。

ls的做法正说明自己的步骤有问题，为什么要修改libc.so？

clfsv2问题请教：为什么需要编译第二次gcc

这个问题的根源在于Richard M. Stallman，甚至可追溯到c语言创建者Ken Thompson、Dennis Ritchie。

gnu工具链分散在三个软件包
binutils——汇编器、连接器
gcc——预处理器、编译器
glibc——c库
好处是灵活，可以使用其他c库，如uclibc、uc-libc、newlib，
坏处是gcc、glibc有循环依赖问题，交叉编译工具链自举时需要编译gcc两遍，
第一遍编译的gcc是裸编译器，也就是没有任何库支持的编译器，只能编译glibc、linux-kernel等一类完全自给自足的软件包，
之后才能编译glibc，
第二遍编译的gcc是全功能的编译器，有glibc的支持，可用来交叉编译任何能想象到的软件包，只是难易程度的问题。

交叉编译工具链的本质就是在宿主上生成目标机代码的工具，自然要链接到宿主c库，交叉编译工具链要处理目标机代码，自然需要目标机c库。

如果把3者整合到一个软件包，一遍编译工具链是可能的，可这样与unix哲学相违背。

如果你还要追问为什么这样，只有下面的名言适于你。

RTFSC (Read the F ** ing Source Code : - )
-- Linus Torvalds

多谢回答！！

不过我觉得 LS 没有回答我的问题。

步骤没有问题，也没有争议，但原因和解释却还有些不一样。

我这么做是为了让 gcc 使用刚刚编译的 glibc，这是标准嵌入式做法，编译出来的程序就能在目标板上运行。

你说的这些我都明白，但跟我前面的问题基本上关系不大。

正常的CLFS-Sysroot两遍编译gcc，交叉编译工具链自然会使用刚刚编译的 glibc。
不妨展示一下你的方法，看看到底有没有必要。

嵌入式没有具体标准，目标就是满足需求、客户的需求，我做嵌入式开发的朋友在工程实践中大部分都还在使用2.4系列内核、uclibc；自己玩是另一回事，工程实践中各种苛刻条件、限制、历史遗留问题是你想都不会想到的。

你如果真的明白，就没有所谓的问题了。

昨晚回的太急，所以有的地方没有说清楚！！

我在另外一个帖子里面也看到了 LS 的解释，请看：
http://www.linuxsir.org/bbs/thread332457.html

下面是我回的一些原话，请过目一下：
不知道这算不算是明白了你的意思。

还有你说的嵌入式没有标准我同意，但总有些方法是通用的，我的做法是参数《构建嵌入式系统》做的。

第一遍编译过 gcc 后，用它再编译出目标板的 glibc，然后再用这个 gcc 和 glibc 编译出直接在目标板上运行的程序，虽然没有第二遍的 gcc，但完全可以动态编译 c 程序，然后再把编译出的目标板 glibc 拷贝到目标板系统就可以运行这些动态编译的 C 程序。

上面这些都是经过我实际验证过的，绝对可行。

至于 2.4 内核和 ulibc 这个要看应用，我用的芯片足够强，外围也足够多，跑 2.6 内核没有问题，我们这是个新产品，所以没有什么历史遗留问题，因为我们用到的一些地方 2.4 内核不支持。

我知道 gcc 需要两次编译，不过我想知道的是第二次编译会不会用到编译出的 glibc，因为从 youbest 老大的图上和叙述中是明确不会用到的，但我在实际编译的时候确实是用到了，所以想请教一下。

另外我也知道 LS 是行家，但总感到你说话有些太那个了，可能是我太敏感了。我只是有些疑问，并且又不是那种没有思考或者是实践直接问的那些低级问题，我是深入思考，实际测试过才问的，到现在为止，我还是不清楚答案，可能是高手觉得这个问题不是问题，不想浪费时间，但我是真的不明白，所以请直接给我个痛快的，用不用？有什么用？怎么用？

在下感激不尽！！