另一中LFS的安装

以下纯属个人简介，正在尝试：
安装环境RH9，内核2.4.20-8。
LFS的很大一部分都是在编译toolchain，移植toolchain。我的想法是先做出一个可以启动的内核，然后在该内核上安装pre-complie的toolchain。本地升级toolchain到相应的版本。

RH9中进行的:
1。建立LFS分区，我用的是/dev/hda8(ext2)
2。下载busybox1.1，静态编译busybox.busybox提供了LFS中很多软件包提供的功能
Currently defined functions include:

[, [[, addgroup, adduser, adjtimex, ar, arping, ash, awk, basename,
bbconfig, bunzip2, busybox, bzcat, cal, cat, chattr, chgrp, chmod,
chown, chroot, chvt, clear, cmp, comm, cp, cpio, crond, crontab,
cut, date, dc, dd, deallocvt, delgroup, deluser, devfsd, df, dirname,
dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap, dumpleases, e2fsck,
e2label, echo, egrep, eject, env, ether-wake, expr, fakeidentd,
false, fbset, fdflush, fdformat, fdisk, fgrep, find, findfs, fold,
free, freeramdisk, fsck, fsck.ext2, fsck.ext3, fsck.minix, ftpget,
ftpput, fuser, getopt, getty, grep, gunzip, gzip, halt, hdparm,
head, hexdump, hostid, hostname, httpd, hush, hwclock, id, ifconfig,
ifdown, ifup, inetd, init, insmod, install, ip, ipaddr, ipcalc,
ipcrm, ipcs, iplink, iproute, iptunnel, kill, killall, klogd,
lash, last, length, less, linuxrc, ln, loadfont, loadkmap, logger,
login, logname, logread, losetup, ls, lsattr, lsmod, makedevs,
md5sum, mdev, mesg, mkdir, mke2fs, mkfifo, mkfs.ext2, mkfs.ext3,
mkfs.minix, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint,
msh, mt, mv, nameif, nc, netstat, nice, nohup, nslookup, od, openvt,
passwd, patch, pidof, ping, ping6, pipe_progress, pivot_root,
poweroff, printenv, printf, ps, pwd, rdate, readlink, readprofile,
realpath, reboot, renice, reset, rm, rmdir, rmmod, route, rpm,
rpm2cpio, run-parts, runlevel, rx, sed, seq, setconsole, setkeycodes,
setsid, sha1sum, sleep, sort, start-stop-daemon, stat, strings,
stty, su, sulogin, sum, swapoff, swapon, switch_root, sync, sysctl,
syslogd, tail, tar, tee, telnet, telnetd, test, tftp, time, top,
touch, tr, traceroute, true, tty, tune2fs, udhcpc, udhcpd, umount,
uname, uncompress, uniq, unix2dos, unzip, uptime, usleep, uudecode,
uuencode, vconfig, vi, vlock, watch, watchdog, wc, wget, which,
who, whoami, xargs, yes, zcat, zcip
3。在LFS分区上建立文件系统目录关键是/dev目录，并拷贝busybox的_install目录。
4。在LFS/etc目录下面创建fstab和inittab文件
5。在RH9下面编译linux-2.6.12内核，并安装。
6。修改/boot/grub/grub.conf文件：
关于2.6.12启动部分的内核参数：root=/dev/hda8 noinitrd
删除Initrd映象。我们的启动不需要initrd支持。
7。reboot，进入2.6.12内核中。很干净的文件系统，除了busybox提供的软件没有其他软件。
8。在2.6.12内核中，使用busybox提供的rpm安装binutils,gcc,glibc的编译好的软件包。版本不用最新的。
9。现在toolchain就建立起来了，然后toolchain本地编译新版本的就可以了。

我已经做到第7步了。后面2步还没有弄，周末试试。

中间出个问题，2.6.12内核mount的/dev/hda8怎么是只读的呢？挂载根文件系统，在哪里设置访问属性？在grub.conf中，内核启动参数部分，kernel /boot/..... root/dev/hda8 noinitrd 确信是没有“ro”的。/etc/fstab中/最后参数是1 1，不知道从哪里拷贝的了，这两个不会是只读的意思吧？

大家共同尝试一下。

作者: good02xaut 发布时间: 2006-02-17

欢迎各种新想法。

不过就你的想法有几个问题可以探讨一下：
1、用busybox的命令来代替那些通用命令的方案在使用Linux下问题不大，但如果用在编译的情况下可能就会有问题，我曾经试过用busybox的命令来编译软件包，但经常会出现问题，通过测试和分析，我认为是busybox中的命令属于简化版本，如果编译时候调用了一些未提供的参数则编译会失败，不过这点我想可以通过打补丁的办法来解决，不过可能需要打补丁的软件比较多。
2、使用busybox提供的rpm安装binutils,gcc,glibc的编译好的软件包，这点我总觉得不妥当，而且一个完整的工具链还需要一些命令，这些命令在busybox中没有提供，比如make。

作者: youbest 发布时间: 2006-02-17

第8中安装的 toolchain 是已经编译好的，并不一定适合你的机器。没测试过是否可行。
第9中重新编译toolchain，那是开始第6章的东西。第5章后边的那些软件包都省略了，用busybox 代替。不知道busybox的效果如何和能否覆盖所有需要的包。

不知道这样出来的系统会否纯洁，会不会受到一开始安装的那个toolchain的影响。不过编译2次toolchain的话，应该就没问题了。

不错，感觉思路基本可行，你的实验结果记得写出来。：）。谢谢分享。

至于只读问题，启动参数中加入 rw 试试。

嘿嘿。。。^_^。。

作者: 晨想发布时间: 2006-02-17

谢谢斑竹点评。
1。busybox的里面的命令是简化版本的，不过一般的makefile文件很少会用到复杂的功能。
2。一个完整的工具链有很多发布好的，我手上就有一个40多M。是tar.gz压缩的，连rpm都不用了。解压后，就可以使用的工具链。
bin:
addr2line,ar,as,c++,c++filt,cc,ccache,chrpath,cpp,g++,gcc,gccbug,gcov,gdb,gdbserver,gprof,i686-pc-linux-gnu-c++,i686-pc-linux-gnu-g++,i686-pc-linux-gnu-gcc,insight,ld,ltrace,nm,objcopy,objdump,ranlib,readelf,size,strace,strings,strip,tclsh8.3,tixindex,tixwish4.1.8.1,wish8.3,xxdiff
不知道整个工具链是否够用的。
当然，这个gcc是3.2的，在此基础上编译出4.0的，不是更容易吗？

作者: good02xaut 发布时间: 2006-02-17

1。最好试试再说。youbest说他用过效果不好，你也测试一下，看看效果如何。

2。工具链，如果你喜欢，有专门的脚本制作。而且支持跨越多体系多架构。
但是这个不是LFS的主要目的。

3。是不难，本来 LFS 也不难，对不？：）。
至于这个toolchain是否足够，那也许要装一次才知道，我的/tools/bin目录中很多文件，我不知道是否都用到了。你可以对比一下。

HTML 代码:

[ c++ dd fold i686-pc-linux-gnu-c++ link nice ptx split tic wc
addr2line captoinfo df g++ i686-pc-linux-gnu-g++ ln nl pwd sprof toe who
ar cat diff gawk i686-pc-linux-gnu-gcc locale nm ranlib stat touch whoami
as catchsegv diff3 gawk-3.1.5 i686-pc-linux-gnu-gcc-4.0.2 localedef nohup readelf strings tput xargs
awk cc dir gcc iconv locate objcopy readlink strip tr xtrace
basename c++filt dircolors gccbug id logname objdump reset stty true yes
bash chgrp dirname gcov igawk ls od rm sum tset zcat
bashbug chmod du gencat info m4 paste rmdir sync tsort zcmp
bunzip2 chown echo getconf infocmp make patch rpcgen tac tty zdiff
bzcat chroot egrep getent infokey makeinfo pathchk runtest tack tzselect zegrep
bzcmp cksum env gprof infotocap md5sum pcprofiledump sdiff tail umount zfgrep
bzdiff clear expand grep install mkdir perl sed tar uname zforce
bzegrep cmp expect groups install-info mkfifo pgawk seq tclsh unexpand zgrep
bzfgrep comm expr gunzip join mknod pgawk-3.1.5 sh tclsh8.4 uniq zless
bzgrep cp factor gzexe kill more pinky sha1sum tee unlink zmore
bzip2 cpp false gzip ld mount pod2man shred test updatedb znew
bzip2recover csplit fgrep head ldd msgfmt pr size texi2dvi uptime
bzless cut find hostid lddlibc4 mtrace printenv sleep texi2pdf users
bzmore date fmt hostname ld-old mv printf sort texindex vdir

作者: 晨想发布时间: 2006-02-17

引用:

作者: 终极幻想

2。工具链，如果你喜欢，有专门的脚本制作。而且支持跨越多体系多架构。

请指教，我很感兴趣。

作者: ecserver 发布时间: 2006-02-18

http://kegel.com/crosstool/

作者: 晨想发布时间: 2006-02-18

今天试过了，真的很复杂，不是不能用，是后患太多了。
1。RH9中构建了一个2.6.12的新内核，/dev/hda8作为/root分区，文件系统为ext2。
2.RH9中编译busybox1.1，把_install目录里面的安装到/root。
3。/root中创建/dev设备
4。/root创建etc目录，有3个文件够了。
inittab:
::sysinit:/etc/rc.d/rc.sysinit
::askfirst:/bin/sh
－－－－－－－－－－－－－－－
rc.d/rc.sysinit
#！/bin/sh
mount -a
－－－－－－－－－－－－－－－－
fstab
proc /proc proc defaults 0 0
－－－－－－－－－－－－－－－－
5。grub引导时，kernel参数：noinitrd root=/dev/hda8 rw
6。内核正确引导，进入shell.
以上过程和软盘里的Linux基本一致。进去之后发行这个系统没有任何用处，安装toolchain.
7。找到一个pre-compile的gcc，解压到/toolchain目录。在/toolchain/bin中有了gcc,as,ld等。
8。./gcc hello.c系统提示，无法找到gcc。
很明显，gcc当时是动态编译的，现在/lib下面没有任何东西，系统找不到动态连接器了。
9。将RH9的root /dev/hda3 mount到/disk目录，拷贝/disk/lib目录下面的ld和libc库到/lib。
10。gcc可以正常运行了，但是提示as缺少libbfd库。
11。这个库在/toolchain/lib目录下找到，拷贝到/lib
12。as 缺少libgcc_s.so库，同11步
13。as可以运行，提示ld缺少libdl.so库，从/disk/lib目录下拷贝到/lib
14。ld缺少crt1.o，从/disk/usr/lib拷贝到/usr/lib
15.ld缺少crti.o，从/disk/usr/lib拷贝到/usr/lib
16。ld缺少lc库，拷贝/disk/usr/lib中的libc.a和libc.so到/usr/lib
17。ld缺少libc_nonshared.a，从/disk/usr/lib中拷贝到/usr/lib
18。ld缺少crtn.o，从/disk/usr/lib中拷贝到/usr/lib
19。gcc hello.c运行成功，./a.out输出正确。
20。gcc可以使用。
从过程中发行，仅仅安装编译过的gcc没用，需要太多的库支持
既然gcc能用了，打算安装glibc库，需要make.
那就先安装make，还是需要make，基于源码的安装过程终止。
需要安装很多很多编译好的toolchain成员，基于裸系统的安装的确不好。

现在明白了，一个目标系统如果能够独立运行，必须交叉编译好所有的toolchain才有意义。这样的文件系统才能够自力更生，不断扩展。
当然如果在/root上继续从RH拷贝需要的toolchain支持，一个完整的toolchain也是可以建立的，不过就不是基于src安装了，离LFS越来越远，变得毫无意义。

作者: good02xaut 发布时间: 2006-02-18

有兴趣的话，可以看看CLFS，这个东西也许能帮助你实现你所想要的，不过学习难度也许有点大，加油。

作者: 晨想发布时间: 2006-02-18

是啊，我要的就是CLFS。
以前我就做ARM平台上的内核，rootfs,应用。不过当时那个arm-linux的toolchain是编译好的，直接拿来用了，所有的东东都是在386上交叉编译的。
就是后来看到了LFS，我才想到那个arm-linux的toolchain是怎么出来的。
LFS中的大部分做的就是toolchain，是386＝》386的交叉编译，如果platform改成arm就是386＝》arm的toolchain了。

搞定了LFS，CLFS应该就是个交叉编译的问题了，再深点应该就是CCLFS，不知道又没有。呵呵。
在ARM平台上本地编译代码，这应该是最高境界了吧。
386编译GCC，386上用GCC再编译出一个arm－linux－gcc，386上用arm-linux-gcc编译gcc。最后生成的gcc就应该是CCLFS了吧？可以运行在arm平台的toolchain。
如果再追求，那就从gcc=>i386-linux-gcc=>GCC,从arm平台把gcc逆向回来，这个境界估计是无人可及了。应该叫做CCCCLFS了，呵呵。

作者: good02xaut 发布时间: 2006-02-18

引用:

在ARM平台上本地编译代码，这应该是最高境界了吧。

本地编译怎么又成了最高境界了？。。。嘿嘿。

你说的 CCLFS，也许 Canadian Cross Compiler 就是你所要的。

引用:

386编译GCC，386上用GCC再编译出一个arm－linux－gcc，386上用arm-linux-gcc编译gcc。最后生成的gcc就应该是CCLFS了吧？可以运行在arm平台的toolchain。
如果再追求，那就从gcc=>i386-linux-gcc=>GCC,从arm平台把gcc逆向回来，这个境界估计是无人可及了。应该叫做CCCCLFS了，呵呵。

这个，就是我刚刚说的Canadian Cross。A机器上编译为机器C编译程序的，但是在B机器上运行的编译器。比如你要在i686上编译一个为arm编译的gcc，但是这个gcc要运行在mac上。

我准备仔细看看CLFS，有兴趣的话，一起研究吧，共同学习。：）。

作者: 晨想发布时间: 2006-02-18

在i386平台上编译一个运行在ARM平台的编译器，还不算高境界啊？
用host,和target描述：在host-386上编译出host-arm、target-arm的gcc
你说的那个Canadian Cross：在host-386上编译出host-mac(ppc)、target-arm的gcc
二者雷同，都同时改变了host和target，估计一步搞不定，gcc在host-386上不知道得翻云覆雨多少次。呵呵

没做过，初步设想2部分：
first: host-386编译出host-386,target-arm的gcc
second:host-386,target-arm的gcc编译出host-arm、target-arm的gcc

你说的那个Canadian Cross，好像不能这样，必须一次完成
host-386直接编译出host-ppc,target-arm的gcc。这个和bootstrap都不符合呀，bootstrap要运行3次，你这个只能运行一次，生成的gcc不能再次在386上运行了

越想逻辑越复杂啊。最好就是./configure -platform=ppc target=arm 一次搞定。binutils和glibc也提供一样的配置方案，天下就太平了。呵呵

作者: good02xaut 发布时间: 2006-02-18

恩，算是不错的境界。也是我想学习的。

Canadian Cross 是要分2次的，一次搞不定。

搜索一下网上资源看看。Canadian cross就是2次的。

具体的细节，我还不清楚，学习中。

最后的这个也是很理想的，但是也许没那么容易做到。但是 --host --build 和--target已经非常简便了。主要是补丁需要一点，这个有点困难，尤其对不懂c或者初学者。

作者: 晨想发布时间: 2006-02-19

“Canadian Cross 是要分2次的，一次搞不定。“

这个我不同意，虽然我还不是很清楚过程但是：
在host-386上编译出host-mac(ppc)、target-arm的gcc如果有中间一步的化：
方案1:
host-386上编译出host-ppc－gcc，然后host-ppc-gcc 编译出target-arm的host-ppc-target-arm-gcc.这是错误的.host-ppc-gcc是不能在386的cpu上运行的！
方案2：
host-386上编译出host-386－target-arm－gcc，然后用host-386－target-arm－gcc编译出host-ppc-target-arm-gcc.这也是错误的.host-386－target-arm－gcc虽然能够在386的cpu上运行的，但是生成的目标代码是基于arm的，基于arm的代码怎么能够在ppc上运行呢！
方案2其实是生成ARM本地gcc的方案。

刚才看来CLFS，其实就是建立host-386－target-arm－gcc的，还没有到第二步呢!

作者: good02xaut 发布时间: 2006-02-19

你应该注意到， CLFS不是 Canadian Cross，因为少了一环。

我说要分2次，是从网上看的，至于具体的，我要重新再看看。不过说的肯定没错的。

说到Canadian Cross，我们用这个举例：build-i686,host-mac,target-arm
1。在i686上编译出 i686->mac 的完整toolchain。
2。在mac上编译出 mac->arm 的完整toolchain。
3。arm有toolchain后，可以编译自己的软件了。
不要错误的理解了Canadian Cross的定义。第二次的编译是要去mac机器上的，不是在i686上进行。

顺便提一下，不是所有软件都有 Canadian Cross 这个概念的，不过相信你也知道的：）。

作者: 晨想发布时间: 2006-02-19

这样的两次啊，明白了。
其实是我最开始说的CCCLSF，由一个Host－》另一个HOST＝》另一个target

CLSF:HOST->一个target
CCLSF:HOST->另一个HOST(必然经过CLSF)
CCCLSF：另一个HOST->另一个target
CCCCLSF:另一个HOST->另一个HOST(必然经过CLSF)

所有的软件都可以CLSF，只有编译器才可以CCLSF。
翻译：所有的软件都可以被交叉编译，只有编译器可以自己交叉编译自己。

补充一下我对Canadian Cross的解释：
1.在386上编译一个可以运行在ppc上的gcc,这时跟arm根本就不然。
2.在ppc上建立交叉编译用的arm-linux-gcc.这比(CCCCLSF)在ppc上编译一个运行在arm上的gcc还简单一步呢。

作者: good02xaut 发布时间: 2006-02-19

好像你用错了一个词，是 LFS ，不是 LSF 。除非代表的是其他意思。

没错，你说的 CCCLFS 基本就是 Canadian Cross。

引用:

补充一下我对Canadian Cross的解释：
1.在386上编译一个可以运行在ppc上的gcc,这时跟arm根本就不然。
2.在ppc上建立交叉编译用的arm-linux-gcc.这比(CCCCLSF)在ppc上编译一个运行在arm上的gcc还简单一步呢。

我记得第1步还要把arm的glibc包括进去，但是我一下子忘记是如何进行的了。我要看看。不知道是我记错了，还是什么。

我的意思是：
还用这个举例：build-i686,host-ppc,target-arm
1。在i686上编译出 i686->ppc 的完整toolchain。但是要包括arm的glibc。
2。在ppc上编译出 ppc->arm 的完整toolchain。这个就不改变了。
3。arm有toolchain后，可以编译自己的软件了。

作者: 晨想发布时间: 2006-02-19

是错了.LFS，not LSF。

我没试过，应该是这样的，现在386上安装了gcc－4.0.2，以及其源码包，假设，为实现你的目标
1。用386上的gcc-4.0.2编译4.0.2src./configure -platform=ppc，编译一个ppc-linux-gcc出来。
2。用ppc-linux-gcc再次编译4.0.2src.这时应该没有必要指定-platform了。编译出来了一个可以在ppc上运行的gcc
3.拷贝这个gcc到ppc机子上，同时拷贝4.0.2的src。
4。在ppc上用gcc编译4.0.2src./configure -platform=arm，编译出arm-linux-gcc
大功告成！
至于在其中binutil和libc怎么一起进行的，我就不清楚了。不过过程一定是这样的。

作者: good02xaut 发布时间: 2006-02-19

1。在i386上编译 i386-ppc gcc4.0.2。（没问题）
2。在i386上编译 i386-ppc gcc4.0.2。（这个是干嘛用的？直接用1里边编译出来的不可以？）
3。拷贝过去。（没问题。）
4。在ppc上编译 ppc-arm gcc4.0.2没问题。

这个东西要实践一下才好。可惜没机器。。。

作者: 晨想发布时间: 2006-02-19

是啊,我也是没有环境,弄了一下CLFS就暂停了.:(

作者: youbest 发布时间: 2006-02-19

引用:

作者: 终极幻想

1。在i386上编译 i386-ppc gcc4.0.2。（没问题）
2。在i386上编译 i386-ppc gcc4.0.2。（这个是干嘛用的？直接用1里边编译出来的不可以？）
3。拷贝过去。（没问题。）
4。在ppc上编译 ppc-arm gcc4.0.2没问题。

这个东西要实践一下才好。可惜没机器。。。

2步是必不可少的。
从1出来的那个ppc-linux-gcc可以编译任何一个程序，使之运行在ppc的CPU。
ppc-linux-gcc -o hello hello.c
生成的hello程序，只能够运行在ppc机子上的。
可ppc-linux-gcc本身还是host386的程序，自己是个交叉编译器而已。拷贝到ppc上也运行不了的。

有了第2步就不一样了。简单一下：）
ppc-linux-gcc -o gcc gcc.c
生成的这个gcc才可以在ppc上运行。这个ppc的target是ppc的。

如果在第2步
ppc-linux-gcc -o gcc gcc.c之前：
采用./configure -platform＝arm配置
生成的gcc就是第4步的结果了。不过这样做有个坏处，就是没有得到ppc上的本地编译器。
这个过程好像和前面我说的有矛盾，不过这次的对！睡了一觉，就认识深刻了

编译gcc时用的GCC决定gcc的host,配置gcc的-platform＝xxx决定生成gcc的target。

没有ppc可以从x86向x64架构上CCCLFS啊，64位CPU的机子还是比较容易找到的。

作者: good02xaut 发布时间: 2006-02-19

我们尽量规范一下表达，这样大家都容易理解对方在说什么：

Cross Compiler 就简称 CC 就好了，每次都打这么多，太累。

Canadian Cross Compiler 就简称 CCC ，打的时候别少了一个C。：）。

对于 CCC：
1。如果是运行在A机器上，为B机器编译的，其结果运行在C机器上的编译器，（build=A, host=B, target=C），
这样我们就说是 A.B-C 编译器。具体例子：i686.ppc-arm 编译器，运行在i686上，编译出的gcc是运行在ppc上，这个gcc是为arm编译程序的。

2。对于普通的 Cross 编译，那么就 A-B 编译就可以了。
这个可以是软件的交叉编译，也可以是 CC 的编译，如 CLFS 用的就是这个。

作者: 晨想发布时间: 2006-02-19

刚刚的这个帖子，让我想到了一个问题。

我们上边提到的 Canadian Cross 的方法是错误的（是我一开始的误导造成的，sorry），搜索了网上资料，确定了我这个想法。

拿 i686.ppc-arm 做例子，正确的应该是：
1。在 i686 上，编译一个 i686-ppc 的 toolchain。
2。在 i686 上，编译一个 i686-arm 的 toolchain。
3。在 i686 上，编译一个 ppc-arm 的 toolchain。
第三步出来的toolchain，就是要拷贝到ppc的toolchain。我这次说的绝对没错。（我就说昨天总觉得怪怪的，但是又找不到原因，就是我弄错了CC的原理！）

这3次编译都在 i686 上进行。不然 Canadian Cross 也就失去了意义了。具体的操作，我要继续深入研究。不过相信很快会得到答案。

谢谢你的参与。没有和你这翻讨论，我都不能彻底领悟到CC呢。：）。

作者: 晨想发布时间: 2006-02-19

要找个机会实践一下。

作者: youbest 发布时间: 2006-02-19

引用:

作者: 终极幻想

刚刚的这个帖子，让我想到了一个问题。

我们上边提到的 Canadian Cross 的方法是错误的（是我一开始的误导造成的，sorry），搜索了网上资料，确定了我这个想法。

拿 i686.ppc-arm 做例子，正确的应该是：
1。在 i686 上，编译一个 i686-ppc 的 toolchain。
2。在 i686 上，编译一个 i686-arm 的 toolchain。（错误！:confused: ）
3。在 i686 上，编译一个 ppc-arm 的 toolchain。
第三步出来的toolchain，就是要拷贝到ppc的toolchain。我这次说的绝对没错。（我就说昨天总觉得怪怪的，但是又找不到原因，就是我弄错了CC的原理！）

这3次编译都在 i686 上进行。不然 Canadian Cross 也就失去了意义了。具体的操作，我要继续深入研究。不过相信很快会得到答案。

谢谢你的参与。没有和你这翻讨论，我都不能彻底领悟到CC呢。：）。

附近是我用world画的流程， Canadian Cross 过程分2步编译完成。这两次编译都在host-386上进行。
如果还是有岐义，我就崩溃了。呵呵

上传的附件

arm-linux-gcc.doc (22.5 KB, 21 次查看)

作者: good02xaut 发布时间: 2006-02-19

我比较赞成good02xaut的观点：
1。在 i686 上，编译一个 i686-ppc 的 toolchain
2。然后利用这个i686-ppc编译出ppc-arm的toolchain。
觉得“在 i686 上，编译一个 i686-arm 的 toolchain”这步是多余的。

作者: youbest 发布时间: 2006-02-19

i686-ppc 不能直接编译出 ppc-arm 的 toolchain 。

你可以试试，因为这个并不需要 ppc/arm 这2台机器，这个就是 CC 的强大之处。CC 只需要1台机器！
运行最后的那个toolchain才需要第二台机器。第三台机器用不到，除非你要测试第二台编译出来的内容。
CC 肯定需要三步。而且都是在同一台机器完成的。

楼上的两位先崩溃一下，我想想怎么解释我说的第一句话。

作者: 晨想发布时间: 2006-02-19

在i686下编译一个在i686下运行并产生ppc下代码的GCC——i686-ppc
然后在i686下运行i686-ppc将产生运行于ppc下的GCC，但这个GCC用来编译出在arm下运行的代码，这个GCC不就是ppc-arm嘛。
挺符合逻辑的。
目前还没崩溃。

作者: youbest 发布时间: 2006-02-20

问题是：
然后在i686下运行i686-ppc将产生运行于ppc下的GCC，但这个GCC用来编译出在arm下运行的代码。

没有 i686.ppc-arm 的 toolchain，你的 i686.i686-ppc 是产生不了 ppc.ppc-arm toolchain 的。帅哥可以试试，我这个是以前看到的信息，我正在实验中。

作者: 晨想发布时间: 2006-02-20

CC 只需要1台机器！严重同意啊
版主没看附件吗？两次编译都是在同一台386上进行的啊

i686-ppc 不能直接编译出 ppc-arm 的 toolchain？这是什么意思?
我画的流程哪里有问题，你直接在里面改比较好理解。

toolchain一旦做好，就死了，对toolchain是不能二次编译的。只能对源码多次编译呀
你做那么多toolchain没有意义的啊

如果./configure --target=arm
make （ppc-linux-gcc作为编译器）
这样做违背了交叉编译器的规则，那我就相信“i686-ppc 不能直接编译出 ppc-arm ”。
不过如果交叉编译器不能够编译编译器的话，Canadian Cross 就不会存在了。

所以，我觉得还是我说的对。呵呵
希望能够尽快得到版主的流程图描述，那样讨论更清楚些。

作者: good02xaut 发布时间: 2006-02-20

引用:

作者: 终极幻想

问题是：
然后在i686下运行i686-ppc（ppc-linux-gcc)将产生运行于ppc下的GCC(./configure --target=arm），但这个GCC用来编译出在arm下运行的代码。
完全同意

没有 i686.ppc-arm 的 toolchain，你的 i686.i686-ppc 是产生不了 ppc.ppc-arm toolchain 的。帅哥可以试试，我这个是以前看到的信息，我正在实验中。

这句没明白什么意思，不好意思；）

按照我附件的流程，其实中间把在i386上做一个ppc上本地编译器的过程给省了。所以将来在ppc上是没有本地编译器的。就好比我的机子上没有gcc，但我可以从别人的那拷贝一个arm-linux－gcc交叉编译器过来用的。

作者: good02xaut 发布时间: 2006-02-20

我暂时先退出讨论，之前是凭经验发表意见的，等有了实际经验在说。

作者: youbest 发布时间: 2006-02-20

楼上可以试试。
最好的就是用arm-linux-gcc编译一个gcc出来
在i386的机子上:
./configure --target=arm 。。。
make(编译器为：arm-linux-gcc)，只编译一遍gcc，不能用bootstrap
如果能够编译成功，那么就一定可以按照我说的来了。

作者: good02xaut 发布时间: 2006-02-20

引用:

作者: good02xaut

i686-ppc 不能直接编译出 ppc-arm 的 toolchain？这是什么意思?
我画的流程哪里有问题，你直接在里面改比较好理解。
.
.
.
如果./configure --target=arm
make （ppc-linux-gcc作为编译器）
这样做违背了交叉编译器的规则，那我就相信“i686-ppc 不能直接编译出 ppc-arm ”。

1。你画的是没问题，但是事实上是做不到的。我的这句话你是不是还是觉得不对？我在实验，你也实验一下，这样好对照。：）。

2。你这个 configure 出来的结果应该是 i686.i686-arm，你的 ppc-linux-gcc编译器是什么意思？是说 host=ppc target=linux 么？看看我上边红字的约定，不然容易造成混乱。

作者: 晨想发布时间: 2006-02-20

ppc-linux-gcc是交叉编译器。他运行于386平台，编译出来的代码可以在ppc上执行。
configure 出来的结果应该是 i686.i686-arm?
这个结果取决与makefile中选的CC

CC=gcc，你说的没错，用本地编译器编译，出来的肯定就是个运行于386平台
CC＝ppc-linux-gcc呢?这可是在用交叉编译器编译程序呢，出来的程序（gcc）怎么会在386上运行呢？

作者: good02xaut 发布时间: 2006-02-20

http://gcc.gnu.org/install/old.html

Installing GCC: Old documentation

2.Specify the host, build and target machine configurations. You do this when you run the configure script.
The build machine is the system which you are using, the host machine is the system where you want to run the resulting compiler (normally the build machine), and the target machine is the system for which you want the compiler to generate code.

看来一步就可以搞定了，build=386 host=ppc target=arm。呵呵。
不过这是老的安装参数，新版gcc好像没有build和host参数了。

作者: good02xaut 发布时间: 2006-02-20

呵呵，一步是可以搞定，不过是要你的 toolchain 都齐全的情况下。你现在是要建立 toolchain，：）。鸡和蛋的问题。

你试试用gcc这么做一次，肯定失败。
--build --host --target 都存在，怎么可能不存在呢。呵呵。
给你看看你所想的结果：

HTML 代码:

# ../gcc-4.0.2/configure \
 --build=i686-pc-linux-gnu \
 --host=x86_64-pc-linux-gnu \
 --target=i386-pc-linux-gnu
loading cache ./config.cache
checking host system type... x86_64-pc-linux-gnu
checking target system type... i386-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for x86_64-pc-linux-gnu-gnatbind... no
checking for gnatbind... gnatbind
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... no
The following languages will be built: c,c++,java,objc
*** This configuration is not supported in the following subdirectories:
 target-libada target-libgfortran
 (Any other directories should still work fine.)
checking for bison... bison
checking for bison... bison -y
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
../gcc-4.0.2/configure: line 3020: x86_64-pc-linux-gnu-gcc: command not found
*** The command 'x86_64-pc-linux-gnu-gcc -o conftest -g -O2 conftest.c' failed.
*** You must set the environment variable CC to a working compiler.

作者: 晨想发布时间: 2006-02-20

引用:

作者: good02xaut

ppc-linux-gcc是交叉编译器。他运行于386平台，编译出来的代码可以在ppc上执行。
configure 出来的结果应该是 i686.i686-arm?
这个结果取决与makefile中选的CC

CC=gcc，你说的没错，用本地编译器编译，出来的肯定就是个运行于386平台
CC＝ppc-linux-gcc呢?这可是在用交叉编译器编译程序呢，出来的程序（gcc）怎么会在386上运行呢？

ppc-linux-gcc：运行于 i386 平台。为 ppc 编译程序。你应该用 i386-ppc gcc来表示。这个是标准的表示方法。你的表达正好反过来了。

作者: 晨想发布时间: 2006-02-20

我现在彻底清楚了。
../gcc-4.0.2/configure \
--build=i686-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \
--target=i386-pc-linux-gnu
配置以后，其实编译时，make 会自动去找x86_64-pc-linux-gnu编译器的。我说的都是显示指定，而现在是通过配置，有make去完成了。
还是回到从前说的：
../gcc-4.0.2/configure \
--build=i686 \
--host=ppc \
--target=arm
这样执行一下你看看，系统肯定会提示找不到ppc－linux-gcc这个东东。
这不正视校验我画的流程了吗，现有交叉编译器，然后直接编译gcc就可以了

作者: good02xaut 发布时间: 2006-02-20

引用:

作者: 终极幻想

ppc-linux-gcc：运行于 i386 平台。为 ppc 编译程序。你应该用 i386-ppc gcc来表示。这个是标准的表示方法。你的表达正好反过来了。

按照约定是你说的

不过我表达的意思，版主应该清楚了吧

标准命名更正后，流程：
/***host-target-gcc***/

./configure --target =ppc --host=386 --build=386
/make (i386-i386-gcc是编译器)
||
||第一次编译
||
./configure --target=arm --host=ppc --build=386
/make (i386-ppc-gcc是编译器）
||
|| 第二次编译
||
ppc-arm-gcc

作者: good02xaut 发布时间: 2006-02-20

不分开两个帖子了。一个讨论。

引用:

作者: good02xaut

按照约定是你说的

一般是不把host指定在name中的，world里有提的：）

不过我表达的意思，版主应该清楚了吧

我的约定是 build.host-target。你的确没按照这个来啊。host不指明，是因为默认为 host=build。但是我们现在是讨论 CC，最好也说出来，毕竟有3个系统在这里。

引用:

作者: good02xaut

我现在彻底清楚了。
../gcc-4.0.2/configure \
--build=i686-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \
--target=i386-pc-linux-gnu
配置以后，其实编译时，make 会自动去找x86_64-pc-linux-gnu编译器的。我说的都是显示指定，而现在是通过配置，有make去完成了。
还是回到从前说的：
../gcc-4.0.2/configure \
--build=i686 \
--host=ppc \
--target=arm
这样执行一下你看看，系统肯定会提示找不到ppc－linux-gcc这个东东。
这不正视校验我画的流程了吗，现有交叉编译器，然后直接编译gcc就可以了

说的不错，是ppc-gcc 找不到。

我正想说的就是，我正在尝试不进行第二步直接进行第三步。答案尽快贴出！

作者: 晨想发布时间: 2006-02-20

好的，严格遵守版主指示。build.host-target命名，在后面加个-gcc不介意吧：）

如果主机只有i386.i386-i386-gcc，不可能一步跳到i386.ppc-arm-gcc的。
必须经过第二步，产生i386.i386-ppc-gcc,才能够编译出i386.ppc-arm-gcc。
个人认为：
./configure --target=arm --host=ppc --build=i386这3个参数里面，--build是没有用处的。整个过程使用的编译器必须是i386.i386-ppc-gcc，和i386.i386-i386-gcc没有任何关系的

一定需要i386.i386-ppc-gcc，肯定是Lib和binutils的问题。只有发现了i386.i386-ppc-gcc后，make才会觉得系统上已经有了合适的Lib和binutils。从程序的角度上说，i386.i386-i386-gcc，一步跳到i386.ppc-arm-gcc没有任何问题的。可是gcc编译的过程需要其他软件的支持太多，系统必须尽可能的知道周围的环境

回答完毕：）

作者: good02xaut 发布时间: 2006-02-20

谢谢，我只是想看的时候更直观，不用琢磨另外的参数是什么。你后边加什么都可以。嘿嘿。

引用:

个人认为：
./configure --target=arm --host=ppc --build=i386这3个参数里面，--build是没有用处的。整个过程使用的编译器必须是i386.i386-ppc-gcc，和i386.i386-i386-gcc没有任何关系的

一定需要i386.i386-ppc-gcc，肯定是Lib和binutils的问题。只有发现了i386.i386-ppc-gcc后，make才会觉得系统上已经有了合适的Lib和binutils。从程序的角度上说，i386.i386-i386-gcc，一步跳到i386.ppc-arm-gcc 没有任何问题的。可是gcc编译的过程需要其他软件的支持太多，系统必须尽可能的知道周围的环境

正确。不过这个是要在 toolchain 建立起来后，才会有的效果。
如果没有任何一部分，都会导致失败。我怀疑等我们把这个问题弄清楚的话，我们就是 toolchain 专家了。。。。。

作者: 晨想发布时间: 2006-02-20

CLFS走一遍就可以建立toolchian，i386.i386-ppc-gcc就产生了。
CLFS走二遍，我们不就到终点了。
为i386.ppc-arm-gcc的提前诞生，庆祝一下

我的机子太旧（毒龙1G,256的DDR266内存），估计走不到终点了。实在没有那么多耐心。
走一遍就心满意足了。

有劳版主和youbest兄完成重任了，等你们的好消息。呵呵

有空还得把我的RH9=>liveCD＝>LFS完成，再去细看CLFS。
本来是冲着LFS来的，和版主的讨论严重跑题了，远的不能再远。
不过收获蛮大的；）

看看我最开始提及的CLFS,CCLFS,CCCLFS,CCCLFS，其时那时我的思路还蛮对的，深入下去后思路有些乱，还好最后终于浮出了水面。深刻领悟“有浅入深易，有深入浅难”

作者: good02xaut 发布时间: 2006-02-20

引用:

作者: 终极幻想

呵呵，一步是可以搞定，不过是要你的 toolchain 都齐全的情况下。你现在是要建立 toolchain，：）。鸡和蛋的问题。

　　我要好好检讨一下自己了，很多看来重要的问题都还没有深入的研究，差点就犯了经验主义了。

　　早先我也是想回答可以一步完成的，因为以前曾编译过交叉编译的工具链，不过当时只涉及两个系统，也仔细研究了一下--build、--host和--target三个参数，所以想当然的写了，不过又仔细看了一下之前的回帖，想了想后来又把回答的内容给删掉了，因为实在无法确定是否能成功。
　　现在看来还真悬啊，看来这“想当然”还真的很危险，还是实践出真知啊！

　　等待进一步证实。

作者: youbest 发布时间: 2006-02-20

另一中LFS的安装

热门阅读

热门下载