还是编译核心的问题：（

dselect

在lfs的文档上核心编译这部分有linus的一篇news的链接，他好像很反对删除/us

r/include中的asm这几个目录。他说编译过程中系统 的库和编译核心所需要的库

是不一样的。可是我的E文太菜了：（ 不大懂，所以一到编译核心就晕。

请高手指点一下，谢谢。

linus的话在在如下的章节。
Linux From Scratch: 版本 CVS-20031119
    章 6. 安装基本的系统软件
        安装 Linux-2.4.22 headers

dselect

linus的话
I would suggest that people who compile new kernels should:

- not have a single symbolic link in sight (except the one that the
   kernel build itself sets up, namely the "linux/include/asm" symlink
   that is only used for the internal kernel compile itself)

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven't run a 2.2.13 kernel in a _loong_
time. But those headers were what Glibc was compiled against, so those
headers are what matches the library object files.

And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.

dselect

不好意思，找了半天菜找到完整的：

>Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard
>"don't use kernel headers directly" answer. But neither gcc.c,
>neither the above small program use kernel headers. I suppose he
>referred to /usr/include/linux/* as (I think) he did not understand me.

No. He really meant that you should not use the kernel headers: you
should use the headers that glibc came with. It is probably a redhat bug
that those headers were a symbolic link.

I would suggest that people who compile new kernels should:

- NOT do so in /usr/src. Leave whatever kernel (probably only the
   header files) that the distribution came with there, but don't touch
   it.

- compile the kernel in their own home directory, as their very own
   selves. No need to be root to compile the kernel. You need to be root
   to _install_ the kernel, but that's different.

- not have a single symbolic link in sight (except the one that the
   kernel build itself sets up, namely the "linux/include/asm" symlink
   that is only used for the internal kernel compile itself)

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven't run a 2.2.13 kernel in a _loong_
time. But those headers were what glibc was compiled against, so those
headers are what matches the library object files.

And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.

Is there some documentation file that I've not updated and that people
are slavishly following outdated information in? I don't read the
documentation myself, so I'd never notice ;)

                        Linus