Native Build using the CLFS methodology

CLFS手册更新了，虽然目前只有32bit和的版本mulitlib的版本，但只要稍加修改就可以做出pure64，这样的话32to32 64to64就都实现了，似乎LFS就显得有些多余，而且现在的lfs-svn用的完全是diy-linux的方法，把别人的方法再写一遍似乎没什么意思。
另外我很喜欢CLFS Native中制作Cross-toolchain的方法，把binutils、gcc放到一个目录中，最然这种方法在HLFS中早就使用了，如果有一天编译binutils、gcc、glibc能一气呵成该多好。

CLFS 至少有三中方法，1.x 类似 LFS，2.x 使用 sysroot，还有面向嵌入式的，每种方法又包含手册若干，您说的是那一个手册？
找不到您所谓的 “CLFS Native”。

"32to32 64to64" 是不安全的，有可能影响系统纯度，这是您的误解，您可以在论坛中搜一下“伪交叉编译”。

“binutils、gcc、glibc能一气呵成”这只是风格问题，按目前源码组织风格不现实、同时也缺乏灵活性。
您可以尝试实现这个想法，会比您这么讲有趣的多。

http://cross-lfs.org/view/svn/native/

多谢，看起来不错。
只是这个明明是sysroot的方法，给归类到1.x，不伦不类的。

论坛中 youbest、地球发动机、偶（伪交叉编译部分） 讨论过类似的方法。

按偶的经验，这个系统纯度值得怀疑，主要怀疑位置在临时系统 http://cross-lfs.org/view/svn/native...stem/mpfr.html ，这里很有可能链接到建立工具链时安装的libgmp.so而不是刚刚交叉编译的版本。
如果您按照这个手册做，不妨到此步骤时确认一下会不会出现这个问题。

看看这个

CLFS-native: Copyright © 2005–2008 Joe Ciccone, Jim Gifford, & Ryan Oliver
CLFS-sysroot: Copyright © 2005–2008 Joe Ciccone, Jim Gifford, & Ryan Oliver
CLFS-1.10: Copyright © 2005–2008 Jim Gifford & Ryan Oliver
或许是因为有 Joe Ciccone的参与，所以……
也有可能是因为CLFS-sysroot的目标是不制作临时系统，所有软件都交叉编译，而CLFS-native的目标或许只是去用CLFS-1.x的方法去实现现在的LFS-svn，也就是以后的LFS-7.0
我感觉不会，因为在编译第二遍gcc时没有指定--target，所以编译出的是gcc而不是i686-xxx-linux-gnu-gcc，而第二遍编译时已经改了specs，指向了/tools/lib，所以用这个gcc去编译mpfr，只会在/tools/lib下寻找libgmp.so。
等到以后有空时在虚拟机上试一下。

您过于先入为主、想当然。

“没有指定--target”并不说明相应的变量无定义，而是系统自动赋予默认值，这个您看一看 ./configure 的输出自会明了。

“gcc而不是i686-xxx-linux-gnu-gcc”事实是这两个可执行文件都存在，并且有硬连接关系。

“而第二遍编译时已经改了specs，指向了/tools/lib”这里只是指明交叉编译工具链中的 gcc 默认库搜索路径是${CLFS}/tools/lib。
根据偶的经验，这是多余的步骤，按照 CLFS-Sysroot 方式建立临时系统更简单，这种仿 LFS 方法的唯一好处是升级时临时系统可以重复利用，特别是升级 glibc 时，而 CLFS-Sysroot 方式必须完全重新做才来的安全。

"用这个gcc去编译mpfr，只会在/tools/lib下寻找libgmp.so"注意是${CLFS}/tools/lib，按照我们的目标您这么理解是正确的。
偶怀疑真实情况是连接到${CLFS}/cross-tools/lib/libgmp.so，影响目标系统纯度，这个要实际验证。

偶可以肯定的一点是，mpfr-2.3.1在伪交叉编译的情况下会强硬的、固执的、认死理的连接到宿主libgmp.so（/usr/lib/libgmp.so 视您安装位置而定），除非配置时您指明交叉编译gmp的位置，个人认为这只是小瑕疵不算bug。
mpfr-2.3.2是否有改善偶不清楚。

偶的理解：
这个手册适用于 x86/x86_64 硬件平台，使用类似 CLFS-Sysroot 的方式建立交叉编译工具链，安装到 ${CLFS}/cross-tools；
然后按照类似 LFS 方式编译临时系统，安装到 ${CLFS}/tools（实际上是伪交叉编译，即--build= --host= 赋植相同，只是未显示指明而已，此时效果上伪交叉编译等同于正常编译）；
之后建立基本系统，安装到最终位置，相当于宿主中的${CLFS}/{,usr/}{bin,sbin,lib}；
中间不需要切换内核，不需要boot，但可以chroot。

可是编译第二遍gcc时没有用sysroot参数

http://cross-lfs.org/view/svn/x86/cross-tools/mpfr.html
CLFS1.xsvn有修改但只是在制作cross-toolchain的时候，而制作tempsystem时没有修改，CLFS-native也没有修改，所以我还是坚持我的看法

多谢提醒。
看来 Current Development 1.x 系列手册的系统纯度都值得怀疑，之前偶到是没注意。

要知道这些手册处于开发状态，如果有问题也是很正常的。
这些手册作参考尚可，当“圣经”就比较可笑了，亦不足为据。
您最好还是实际做做再下结论，否则偶只有漠视您的言论。

我过两天就去试验

http://cross-lfs.org/view/svn/
http://cross-lfs.org/view/svn/native/ 失效
CLFS-native 系列手册失踪，已合并到 CLFS-svn，工具链特征是使用了 --sysroot=xxx 并且类似 LFS 调整 头文件 (xxx)/tools/include 库 (xxx)/tools/lib 搜索路径。

出现这种情况，是该死的 libtool 设置 -rpath 覆盖了 伪交叉编译工具链 正常的 -L 库搜索路径所致。
可参考 man ld 中 -rpath -rpath-link 小节，有详细说明。

CLFS-native 被废弃很可能是和类似问题有关。
这再次说明 伪交叉编译 不安全。