内核与GCC的关系，困惑

good02xaut

看了LFS-6.1。
安装的最后一步才是编译新内核2.6.11.12，很奇怪。

1。内核
内核是bin格式文件，编译后的代码不需要任何其他Lib和bin程序的支持。
编译过程使用的头文件也是source/include目录和宿主系统没有关系。
编译时用的GCC版本和make版本只要符合linux-2.6.11.12内核的最低要求一定可以编译成功。
那用GCC-3.2和GCC-3.4编译同一个linux-2.6.11.12生成的内核应该是一样的吧？
在linux-2.4和linux-2.6.2内核上编译同一个linux-2.6.11.12应该也是一样的吧？
个人认为是一样的。

2。反复编译toolchain的问题
binutils,gcc,glibc都反复编译了好多次，这样做无非是把gcc-3.2升级到gcc-3.4.3。由于gcc将来运行的时候需要binutils和glibc的支持，所以他们三者可以看作一个整体一起往复。这个过程无非就是在linux-2.6.2内核上如何升级gcc，和将来的内核升级暂时无关的。

3。编译其他软件的问题
当把gcc升级到3.4.3后，编译其他软件时比如bash，用3.4.3的gcc可能提供更好的代码优化，可是使用的头文件怎么还是2.6.2的呢？如果bash使用了syscall，这个和lib无关和系统有关。2.6.2怎么可以提高满足2.6.11.12的include呢？为什么不直接使用2.6.11.12的header file？


请教高手指点一下，我的这3点的理解是否有问题。
谢谢！

dyhml

1.用 gcc3 和 gcc4 编译的同一个版本的内核肯定不一样,因为 gcc3 和 gcc4 的代码优化不同.
编译过程中可能会链接 宿主系统 的 static库,比如 libz ,libbz2 .

2.因为这3个都要用 linux-libc-header ,chroot 之前用的都是 宿主系统 的.
还有也可能会 static link 到 宿主系统 的 static库,比如 libz ,libbz2 .

上面都是为了让新系统和宿主系统的关系尽可能小, 虽然 static 链接的库,运行时就与宿主系统无关了.

3.chroot之后编译的软件基本与 宿主系统 无关,因为所需要的 linux-libc-header ,glibc, static库 都在 chroot下.
至于 linux-libc-headers ,chroot之后应该安装一个稳定的版本,但 linux-libc-headers 的版本与 linux-kernel 的版本无关. 这是为了在不同内核下编译的软件,用的是同一个 linux-libc-headers ,这样,软件才有更好的移植性. 在 linux-libc-headers 的 README 里说的比我这里清楚.

所以,装 linux-libc-header 应该找比安装的内核版本号小的最新版本 ,比如 ,我这里是
linux-2.6.15.4.tar.bz2 + linux-libc-headers-2.6.12.0.tar.bz2

dyhml

linux-libc-headers-2.6.12.0/doc/README

The linux-libc-headers (llh) package (available at
http://ep09.pld-linux.org/~mmazur/linux-libc-headers/) contains headers
that export linux abi to userspace. These headers are a heavily modified and
cleaned up version of what comes with original linux tarball. See the FAQ
for more details.

Userland usefulness is achieved by removing kernel only parts (which often
generate errors) and using code provided by libc where possible (this allows
to avoid collisions when both linux and libc headers define the same structure
or constant). Unfortunately libc dependency might result in functionality loss
since libcs aren't always in sync with what kernel provides. If such a case
occurs please send a bug report to the maintainer (see AUTHORS file) and, if
possible, a workaround will be added. Do note that since llh is primarily for
2.6 based kernels we assume glibc to be at least version 2.3.3 (as far as I
know this version wasn't released officially but is being used by many current
linux distributions). Glibc is not a requirement though - llh is known to work
with other implementations of standard C library - but obviously is a
priority, so be prepared to send a bugreport if using something else.
In case you're wondering why take such an approach if it's obvious that it
might generate problems. Well, according to my knowledge there is consensus
among kernel hackers as to how userland headers should look like, but
unfortunately proper implementation (and wider adoption) will take time and
something that just plain works (in most cases anyway) is needed now.

good02xaut

这是linux-2.6.12的changes里面的要求：
o  Gnu C                  2.95.3                  # gcc --version
o  Gnu make               3.79.1                  # make --version
o  binutils               2.12                    # ld -v
o  util-linux             2.10o                   # fdformat --version
o  module-init-tools      0.9.10                  # depmod -V
o  e2fsprogs              1.29                    # tune2fs
o  jfsutils               1.1.3                   # fsck.jfs -V
o  reiserfsprogs          3.6.3                   # reiserfsck -V 2>&1|grep reiserfsprogs
o  xfsprogs               2.6.0                   # xfs_db -V
o  pcmcia-cs              3.1.21                  # cardmgr -V
o  quota-tools            3.09                    # quota -V
o  PPP                    2.4.0                   # pppd --version
o  isdn4k-utils           3.1pre1                 # isdnctrl 2>&1|grep version
o  nfs-utils              1.0.5                   # showmount --version
o  procps                 3.2.0                   # ps --version
o  oprofile               0.5.3                   # oprofiled --version
里面根本没有提到库的问题，连静态库也是多余的。代码优化问题是存在的。

dyhml

kernel 编译过程中可能会链接 宿主系统 的 static库,比如 libz ,libbz2

我只是说可能,如果不是的,那就是我错了.