Re: libc headers issue

[Carlos Carvalho <carlos@fisica.ufpr.br>]

David Engel (david@elo.ods.com) wrote on 26 April 1996 22:04:
 >> It means that the headers in /usr/include/linux and
 >> /usr/include/asm do not match the kernel you are running. They
 >> instead match the kernel that the C library was built for. The
 >> only time this is a problem is if you are building a user-mode
 >> tool that relies on a kernel interface that has recently changed
 >> and you are running a C library that is behind the version of your
 >> kernel. In this case you must add -I/usr/src/linux/include to your
 >> command line when building it. Another recent problem was caused
 >> by "accessories" to the kernel not building correctly - "make
 >> menuconfig" in /usr/src/linux was the one that hit me. This seems
 >> to have gone away.
 >
 >Bruce did a good job of answering, but he left out one thing -- the
 >rationale.
 >
 >The intent is to provide a more stable development environment.  When
 >/usr/include/{asm,linux} are linked to the current kernel sources, you
 >run the risk of breaking the compilation of all programs each time you
 >upgrade kernels.  What we have done is provide the headers from a
 >kernel that is know to work with libc.  With this arrangement, you are
 >still free to compile and upgrade kernels as you see fit without
 >affecting the compilation of other programs.  It is hoped that libc
 >distributed by H.J. Lu will eventually adopt this arrangement as well.

I don't understand why the symlink will break "the compilation of all
programs each time you upgrade kernels". This issue only concerns
programs that depend on the kernel, so I think the headers should
reflect the kernel. For example, one will have trouble compiling the
net tools. There may be a problem if the libc doesn't match the
kernel, but in the present way this will also happen, with the
disadvantage of using a lot more disk space.

Carlos