求解释：为什么要有预工具链？

verysmall

为什么要是用预工具链呢？预工具链也是宿主系统生成的，只是版本不一样而已啊！那直接是用宿主系统的工具生成目标系统的工具链不行吗？
哪位可以帮小弟解释下？

adam8157

"运行于宿主机生成目标运行于宿主机"的编译链生成"运行于宿主机生成目标运行于目标机"的编译链, 然后用它去生成"运行于目标机且生成目标运行于目标机的编译链"

问, 没有中间的交叉编译, 如何能生成目标机上跑的编译链呢?
再问, 如果可以像楼主说的那样, 岂不可以不用生成编译链, 直接把目标机要的软件编译好就是了?

PS: 好久之前玩的LFS了, 大概是这么回事...
PPS: 一般遇到的情况其实是一些依赖(例如glibc)的不同, 但是想象成不同架构的交叉编译比较容易理清思路

verysmall

按大哥的思路，拿交叉编译来说：
首先用宿主的机器生成运行于宿主机器上的预工具链
然后用预工具链生成运行在其他平台上的工具链

1: 在预工具链生成的时候需要的内核头文件是怎么一回事？
2: 那请问预工具链生成的HELLO WORLD程序能不能在宿主机器上运行呢？
3: 如果能在宿主机器上运行的话，对我们看来宿主的工具链和预工具链的不同只在于版本和依赖的不同了，对吗？

adam8157

Post by verysmall;2124920
按大哥的思路，拿交叉编译来说：
首先用宿主的机器生成运行于宿主机器上的预工具链
然后用预工具链生成运行在其他平台上的工具链

1: 在预工具链生成的时候需要的内核头文件是怎么一回事？
2: 那请问预工具链生成的HELLO WORLD程序能不能在宿主机器上运行呢？
3: 如果能在宿主机器上运行的话，对我们看来宿主的工具链和预工具链的不同只在于版本和依赖的不同了，对吗？

1, 不清楚, 忘了, 应该是用来指定预编译链生成的目标文件的一些东西, 比如架构和依赖.
2, 不能, 依赖的libc之类的东西不同
3, 版本不同, 依赖相同, 生成的目标文件依赖才不同

PS: 这块儿一直都是理解的难点, 我不敢说我的理解就完全正确, 同求解释 ;)

mrmuxl

预工具链和交叉编译还是有些区别的，这里不讨论交叉编译

楼主如有雅兴不妨找出珍藏已久的LFS6.2的中文文档（我这里只找到LFS6.2的中文的）
翻开第五章第二节工具链技术说明
现摘抄部分内容如下：
第五章的总体目标是提供一个临时环境，您可以 chroot 到这个环境，在里面构建一个第六章中的干净、没有问题的目标 LFS 系统。为了尽量的与宿主系统分开，我们创建了一个自包含、自依赖的工具链。要注意的是，这个创建过程被设计为尽量减少新手犯错误的可能，同时尽可能多的提供教育价值。

这里已经讲得很明白，有两个要点：1、就式是要创建一个自包含、自依赖的
                                                 2、尽量和宿主系统分开的
还有一句就是这个临时的工具链的创建“过程”的设计目的（注意是创建过程）：
1、尽量减少新手犯错误的可能
2、同时尽可能多的提供教育价值
这句话的意思是这个过程并不是一定要这样，还有其他的更方便的，更简洁的方法，这里的这个过程是顺应这两个目的而创建的。

摘录一段：
第五章中构建方法是如何工作的一些技术要点：

这个过程在原理上与交叉编译类似，通过把工具安装在同一个目录(使用相同的"prefix")中以便协同工作，还利用了一点 GNU 的"魔法"。

小心处理标准连接器的库文件搜索路径，确保程序仅连接到指定的库上。

小心处理 gcc 的 specs 文件，告诉编译器要使用哪个动态连接器。

这个讲了具体实际上这个工具链的实现的大体或者说比较具体的方法


摘录如下：

需要使用新动态连接器也是第二遍编译 GCC 需要打 Specs 补丁的原因。不这样做的结果是 GCC 会把宿主系统 /lib 目录下动态连接器的名字嵌入进来，这样有悖于与宿主系统隔离的目标。

第二遍编译 Binutils 的过程中，我们利用 --with-lib-path 选项来控制 ld 的库搜索路径。如前面所指出的，核心工具链是自包含和自依赖的，所以第五章余下的软件包的编译将依赖于 /tools 下新的 Glibc 。

请楼主仔细的看看第五章第二节，然后将第五章强奸一次，在强奸的各个阶段用ldd命令观察新的安装的包的可执行文件的共享库依赖关系，也可以和系统的作比较。
等楼主做完了一定可以达到高潮，哈哈

还可以参考 孙海勇 的一本书，写的不错的

大隐于市

可以参考一下这个，过程简化不少
http://zdbr.net.cn/download/Sysroot-LFS-1.1.htm