| 1234567891011121314151617181920212223242526272829303132333435 |
- <sect2>
- <title>Why we copy the kernel headers and don't symlink them</title>
- <para>In the past, it was common practice for people to symlink the
- /usr/include/linux and asm directories to /usr/src/linux/include/linux
- and asm respectively. This is a <emphasis>bad</emphasis> idea as
- this extract from a post by Linus Torvalds to the Linux Kernel
- Mailing List points out:</para>
- <screen>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.</screen>
- <para>The relevant part here is where he states that the headers should
- be the ones which <emphasis>glibc was compiled against</emphasis>. These are
- the headers which should remain accessible and so by copying them, we ensure
- that we follow these guidelines. Also note that as long as you don't have
- those symlinks, it is perfectly fine to have the kernel sources
- in <filename>/usr/src/linux</filename>.</para>
- </sect2>
|
