CLFS的一点疑问

sspipipipi

根据CLFS手册1.0.0版，在主系统上制作完交叉编译的工具链后，需要制作一个临时系统，这个系统的制作有两种方式，一种就是直接制作一个可以启动目标板的临时系统，我想问下大侠们，有必要用这个系统引导目标板然后按照手册第V部分再次制作系统吗

d00m3d

關鍵在於目的系統的架構（Architecture）是否跟宿主系統架構兼容

sspipipipi

回dOOm3d，目标板的Arch跟系统兼容的话，采用chroot的方法应该回简单一点，不兼容的话无法chroot。我的意思是，用交叉编译工具链，编译出的内核既然已经可以引导目标板，那么，为什么不能把目标板上要用的其他软件也用此工具链交叉编译了呢，不知道将系统一步做到位行不行

sspipipipi

如果目标板运行速度更快的话，比如在i686上交叉编译64bit双核的目标板上的系统，可不可以用交叉编译出来的这个系统引导目标板，然后就在此基础上装软件呢？

tfkdmwmqtr

uname -m 如果显示的是 i686 ，不能 chroot 到 x86_64 的系统中，因为内核是 i686 的不支持64位运算。反过来， uname -m 是 x86_64 的，可以 chroot 到 i386 / i486 / i586 / i686的系统中。
x86_64以及x86（ i386 / i486 / i586 / i686 ) 是不能 chroot 到 MIPS 中的，MIPS也不能 chroot 到 x86 或 x86_64 中。
能否 chroot 不仅与内核有关，还与软件有关，能否 chroot 还要看软件环境是否支持。

if you are going to  chroot 和 if you are going to boot的区别，是 CLFS 区别于 LFS 的重大特点之一。
手册中讲到是选择 if you are going to  chroot 还是选择 if you are going to  boot ，要看临时编译环境完成后测试 /tools/lib/libc.so.6 和 /tools/bin/gcc -v 的输出是否正常，如果没有显示 libc 和 gcc 的版本信息，如果是报错，就不能使用 if you are going to chroot 。这时，应该考虑到是不是你的目标系统架构与你的主系统架构不兼容。比如 内核是 i686 的，想要做的系统是 x86_64 的。这样，只有当你将主系统的内核换为 x86_64 之后，才能支持目标系统的 x86_64 。也就是说内核和系统软件要兼容，如果系统软件编译的是 MIPS 的就超出了 x86 以及 x86_64 所能支持的范围，就不能 chroot 了。
如果你的内核支持目标系统，就可以用 chroot 的方法。比如 x86_64 内核是支持 x86_64 / i686 / i586 / i486 / i386 的。
否则，用 if you are going to boot 的方法。比如当前系统是 x86 ，目标系统是 MIPS ，那还需要有 MIPS 的处理器或者MIPS模拟环境。

另外，建议楼主用 svn 的。 特别是，如果硬件很新，旧内核不一定都能支持。比如，linux-2.6.18.x 的内核不能支持我的笔记本的网卡。而 2.6.22.6 或 更新的都能支持得更好。
如果你用 lfslivecd 来做，想用 chroot 的方法构建 64位系统，在启动 lfslivecd 的时候用 64 位的内核。
32位适合办公、娱乐、学习用。64位多媒体弱一些。

d00m3d

tfkdmwmqtr 已解释得够详细了，昔日我也有相似的疑问，看完手册的解说终於也明白当中理据，CLFS 手册这个部份晨想斑竹写得真好。

BTW，晨晨那家伙去哪了？

sspipipipi

比较郁闷哦，似乎我说的不是很清楚，我的重点不是在问大家我应该选chroot方式还是boot方式，我是想问问大伙，为什么交叉编译出来的系统不能作为目标板的最后系统而仅仅是个临时系统

sspipipipi

CLFS1.0.0中7.11开头的地方说了这样一段
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.
我不太明白为什么交叉编译的内核不能作为最终的目标板系统内核，按理说应该可以才对呀。而且，交叉工具链如果能编译出内核，又为什么不能将其他的软件也交叉编译了呢，这样的话系统不就一步到位了吗？CLFS手册没有这样做，它在第V部分装完基本软件后重新编译了内核。这样的话，我觉得交叉编译就变的没什么意义了，因为最后的系统实际上还是按照LFS的路子做出来的，而交叉编译出来的东西在这里也就充当了一次LFS的liveCD的角色。

sspipipipi

说成包含了工具链的liveCD似乎更合适

tfkdmwmqtr

我也想过在 x86 系统中将所有 Pure64 或者 MIPS 需要的软件编译出来，但那样是无意义的。
软件好不好用，要真实的用过才知道。如果我没有 64 位的处理器，也不能模拟64位的环境，编译出 64 位的软件是无意义的。

如果我现在有一台 MIPS ，但是我手上只有 x86 的 Linux 系统，我可以在 x86 的机器上编译出 MIPS 的基础软件和内核，将编译好的开发工具拿到 MIPS 机器 的硬盘上就可以继续制作 MIPS 的系统了。