对LFS6.1.1工具链的理解
时间：2006-09-09 来源：augustusqing
经过几天的奋战，终于又搞了遍lfs，在第六章的perl5.8.7测试时有一项错误，开始不敢继续下去，后来听linuxsir上幻想版主的建议，忽略错误继续下去，到后来，很多测试都懒得做了，这样速度里面就快了，昨天晚上终于做好！
今天上午来，又学习了那篇关于库的深入思考的帖子，再在自己做好的lfs里实验了一番，总结了say.c调用动态库say.so到test，到运行的过程，自己对自己理解的东西还比较满意
还总结了lfs中工具链的调整，这工作就是在搞清出程序编译，动态链接过程中做的
在第六章开始构建最后目标系统时，编译安装glibc时，他有--prefix=/usr的选项，可install后，有几个程序，比如ldconfig，装在了/sbin下面了，怎么会到这个目录来了了？而在第五章中装在/tools下面的glibc中，这个ldconfig又会装在哪里了？（当装glibc时，指定的prefix是/usr时，会自动把一部分程序和库装在/sbin和/lib下面，当prefix是别的目录时，比如/tools，那么所有的程序和库都会装在相应的prefix目录下（linuxsir上面获得））
动态连接器由 Glibc 提供，用来找到并加载一个程序运行时所需的共享库，在做好程序运行的准备之后，运行这个程序
小心处理标准连接器的库文件搜索路径（在编译binutils时，make －C ld LIB_PATH=/tools/lib,设置的就是ld的默认库搜索路径）
小心处理 gcc 的 specs 文件，告诉编译器要使用哪个动态连接器。
连接器的一个重要方面是它的库搜索顺序，将 --verbose 选项传递给 ld 可以获得详细的信息。例如，输入命令：ld --verbose | grep SEARCH 将显示当前搜索路径和顺序。要显示 ld 连接的是哪些文件，可以编译一个伪(dummy)程序并把 --verbose 选项传递给连接器。举个例子，输入 gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded 将显示所有连接成功的文件。
虚拟内核文件系统(Virtual Kernel File Systems)，是指那些是由内核产生但并不存在于硬盘上(存在于内存中)的文件系统，他们被用来与内核进行通信。（主要是指proc和sysfs文件系统）
env 命令的参数 -i 的作用是清除所有 chroot 环境变量。
/var/run/utmp 记录着现在登录的用户
/var/log/wtmp 记录所有的登录和退出
/var/log/lastlog 记录每个用户最后的登录信息。/var/log/btmp 记录错误的登录尝试
工具链技术总结：
1 把binutils编在/tools下，并准备好设置了LIB_PATH=/tools/lib的ld的编译，但没有安装，安装要到glibc装好后，再安装这个ld，那么再安装这个ld之前，用的ld的默认搜索路径还是/usr,/usr/lib类
2 gcc第一遍，主要--prefix=/tools，--libexecdir=/tools/lib(location of program executables)
3 glibc第一遍，--prefix=/tools --with-binutils=/tools/bin,装在tools下，并保证用正确的binutils程序
4 第一遍调整工具链。此时就可以装上面设置了LIB_PATH的ld程序了，再调整gcc的spec文件指向新的动态连接器，此时的gcc应该是刚才装好的（在前面把/tools/bin设置在PATH的最前面了，并且同+h关闭了bash的hash功能），(根据查看我现在装好的lfs系统上的/tools下的gcc的spec和/usr下的gcc的spec文件，它们的此时的ld-linux.so.2前的路径都是/lib),把这个gcc的spec中的ld-linux.so.2的路径改到/tools/lib下，确保以后用gcc编译好的程序的动态连接器是新编出的，因为指向动态连接器的固化路径会被嵌入到每个elf可执行文件中
5 第二遍编译gcc了，此时编译时的ld会链接新的glibc下面的库，但默认的仍会使用宿主系统/lib下的动态连接器，于是打spec的补丁，这样，就可以以保证新的动态连接器在编译 GCC 的时候就用上（把新的动态连接器了作为编译出来的gcc的动态连接器，不知道这样理解对不对？此时新编译出来的gcc的spec中的ld-linux.so.2的路径应该是/tools/lib了，但根据上面在lfs系统上查的结果，是不对的，可能会在后面的第二次调整再改过来了）
6 第二遍binutils，说是利用--with-lib-path=/tools/lib指示 configure 脚本在 Binutils 编译过程中将传递给连接器的库搜索路径设为 /tools/lib ，以防止连接器搜索宿主系统的库目录（这个时候在用的ld应该是/tools下面的ld了，那么这个ld在之前设置了LIB_PATH=/tools/lib了，应该这个选项是多余的吧？），再预备编译设置了新的LIB_PATH=/usr/lib,/lib的ld，为将来的再次调整做准备
7 编译第二遍的glibc，（此时用的所有工具都是/tools下面的了，这个点的状态是：ld用的是LIB_PATH为/tools/lib，gcc的spec中的ld-linux.so.2的路径应该是/tools/lib。）把glibc装在/usr下面，根据最开始的疑问解答，当glibc的prefix为/usr时，会把一部分程序和库装下/sbin和/lib下
8 第二遍调整工具链。安装前面准备的设置了LIB_PATH为/usr/lib,/lib的ld，这以后的程序编译时的ld就只会链接/usr/lib,/lib下的库了；再调整gcc的spec，此时的gcc就是/tools下的，把它的spec中的ld-linux.so.2调回到新编译的最后系统的glibc下，/lib下，这就验证了前面预言，解决了前面实验的矛盾
9 第三遍binutils，--prefix=/usr，并把可执行文件的安装目录也设在/usr下
10 第三遍gcc。此时把gcc装在/usr下，--libexecdir=/usr/lib，可执行程序装在/usr/lib下，相应的编出来的gcc的spec中的linux-li.so.2的路径就是默认的/lib了，就是最后lfs系统的gcc的spec了
11 完成 刚才又在linuxsir上看到了一篇精华贴，差不多也是对工具链的理解，对照一下，我的理解还是满对的，不过就是感觉自己说的太烂了，别人写得条理清晰，好读得多啊 http://www.linuxsir.org/bbs/showthread.php?t=240687
小心处理标准连接器的库文件搜索路径（在编译binutils时，make －C ld LIB_PATH=/tools/lib,设置的就是ld的默认库搜索路径）
小心处理 gcc 的 specs 文件，告诉编译器要使用哪个动态连接器。
连接器的一个重要方面是它的库搜索顺序，将 --verbose 选项传递给 ld 可以获得详细的信息。例如，输入命令：ld --verbose | grep SEARCH 将显示当前搜索路径和顺序。要显示 ld 连接的是哪些文件，可以编译一个伪(dummy)程序并把 --verbose 选项传递给连接器。举个例子，输入 gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded 将显示所有连接成功的文件。
虚拟内核文件系统(Virtual Kernel File Systems)，是指那些是由内核产生但并不存在于硬盘上(存在于内存中)的文件系统，他们被用来与内核进行通信。（主要是指proc和sysfs文件系统）
env 命令的参数 -i 的作用是清除所有 chroot 环境变量。
/var/run/utmp 记录着现在登录的用户
/var/log/wtmp 记录所有的登录和退出
/var/log/lastlog 记录每个用户最后的登录信息。/var/log/btmp 记录错误的登录尝试
工具链技术总结：
1 把binutils编在/tools下，并准备好设置了LIB_PATH=/tools/lib的ld的编译，但没有安装，安装要到glibc装好后，再安装这个ld，那么再安装这个ld之前，用的ld的默认搜索路径还是/usr,/usr/lib类
2 gcc第一遍，主要--prefix=/tools，--libexecdir=/tools/lib(location of program executables)
3 glibc第一遍，--prefix=/tools --with-binutils=/tools/bin,装在tools下，并保证用正确的binutils程序
4 第一遍调整工具链。此时就可以装上面设置了LIB_PATH的ld程序了，再调整gcc的spec文件指向新的动态连接器，此时的gcc应该是刚才装好的（在前面把/tools/bin设置在PATH的最前面了，并且同+h关闭了bash的hash功能），(根据查看我现在装好的lfs系统上的/tools下的gcc的spec和/usr下的gcc的spec文件，它们的此时的ld-linux.so.2前的路径都是/lib),把这个gcc的spec中的ld-linux.so.2的路径改到/tools/lib下，确保以后用gcc编译好的程序的动态连接器是新编出的，因为指向动态连接器的固化路径会被嵌入到每个elf可执行文件中
5 第二遍编译gcc了，此时编译时的ld会链接新的glibc下面的库，但默认的仍会使用宿主系统/lib下的动态连接器，于是打spec的补丁，这样，就可以以保证新的动态连接器在编译 GCC 的时候就用上（把新的动态连接器了作为编译出来的gcc的动态连接器，不知道这样理解对不对？此时新编译出来的gcc的spec中的ld-linux.so.2的路径应该是/tools/lib了，但根据上面在lfs系统上查的结果，是不对的，可能会在后面的第二次调整再改过来了）
6 第二遍binutils，说是利用--with-lib-path=/tools/lib指示 configure 脚本在 Binutils 编译过程中将传递给连接器的库搜索路径设为 /tools/lib ，以防止连接器搜索宿主系统的库目录（这个时候在用的ld应该是/tools下面的ld了，那么这个ld在之前设置了LIB_PATH=/tools/lib了，应该这个选项是多余的吧？），再预备编译设置了新的LIB_PATH=/usr/lib,/lib的ld，为将来的再次调整做准备
7 编译第二遍的glibc，（此时用的所有工具都是/tools下面的了，这个点的状态是：ld用的是LIB_PATH为/tools/lib，gcc的spec中的ld-linux.so.2的路径应该是/tools/lib。）把glibc装在/usr下面，根据最开始的疑问解答，当glibc的prefix为/usr时，会把一部分程序和库装下/sbin和/lib下
8 第二遍调整工具链。安装前面准备的设置了LIB_PATH为/usr/lib,/lib的ld，这以后的程序编译时的ld就只会链接/usr/lib,/lib下的库了；再调整gcc的spec，此时的gcc就是/tools下的，把它的spec中的ld-linux.so.2调回到新编译的最后系统的glibc下，/lib下，这就验证了前面预言，解决了前面实验的矛盾
9 第三遍binutils，--prefix=/usr，并把可执行文件的安装目录也设在/usr下
10 第三遍gcc。此时把gcc装在/usr下，--libexecdir=/usr/lib，可执行程序装在/usr/lib下，相应的编出来的gcc的spec中的linux-li.so.2的路径就是默认的/lib了，就是最后lfs系统的gcc的spec了
11 完成 刚才又在linuxsir上看到了一篇精华贴，差不多也是对工具链的理解，对照一下，我的理解还是满对的，不过就是感觉自己说的太烂了，别人写得条理清晰，好读得多啊 http://www.linuxsir.org/bbs/showthread.php?t=240687
相关阅读 更多 +
