挖个坑，关于 toolchain 编译以及 系统编译 的小问题。

晨想

我突然想到一个问题，发个帖子讨论一下：）。

大家都知道，LFS 从 5（V4 我不清楚）到 6，都是用过修改 gcc  的 specs 来达到净化目的的，然后再 chroot 进去编译新的系统。

CLFS 1 虽然是更新了方式，但是还是一样要修改 specs 的，只是多了一个一开始的 cross toolchain 的编译。换汤不换药。

CLFS 2 (sysroot) 则采用全新的方式，不修改 specs，直接一次性搞定，方便快捷，但是难度也高。

我的问题是：是不是 LFS / CLFS 1 的方法，其实都不是 gcc / glibc / binutils  开发者的原意；真正要达到净化或者说隔离，就应该要用 sysroot 那个方法？虽然这种方法因为用的少，所以也有很多地方不完美，不如 native 的完善，但是我觉得这个方式也许是开发者的原意，你们的意见？

等待高人的论点和证明。：）。

manphiz

个人理解交叉编译就是从一个架构的宿主机生成另一架构的目标机代码的过程。 native 和 sysroot 二者应该能够达到完全相同的目标代码，可以看成达到同一目标的两种方法，各有优劣

youbest

我个人感觉应该是gcc,binutils本身设计的时候就考虑交叉编译的问题(sysroot方式)，而大部分软件（不是全部）估计没有直接考虑交叉的方式(sysroot方式)，更多的估计是考虑跨平台的问题。

晨想

的确是大部分软件都没有为 sysroot 着想。从 LFS 里边的那么多软件可以看到，几乎每个软件都要修改那么一点东西的。

那 sysroot 就是用来搞一个 toolchain 然后再 cross 一个系统出来就差不多了到头了，每个软件都要补丁一下的话，会死人的说。

那我想知道，如果一个软件想支持 sysroot 的话，是不是在 configure 的时候，就要把相应的内容检测好？比如说 headers/libs 的搜索路径等。gcc会正确连接的，但是软件自己不会去找正确内容，问题是这个，没错吧？

d00m3d

可是 sysroot 方式好像还未定型，64 bit 的 x86 又或 multilib 似乎都未有方案。。。