> /usr/include/sys/debugreg.h has:
> #include <linux/debugreg.h>
As long as you include <linux/foo.h> you will have trouble.
The contents of <linux/foo.h> are essentially random.
Including this file may not be possible because bad things
are not hidden behind #ifdef __KERNEL__ etc.
In this particular case the entire file has disappeared.
The conclusion is that each line #include <linux/something.h>
in glibc is a bug in glibc.
(Each individual time this causes a problem one may blame the kernel,
but it has happened hundreds of times and will continue to happen.)
The solution is simple: there is a subdirectory /usr/include/linux
that is not a symbolic link to kernel headers but part of the glibc
distribution. A few times a year, when a new glibc is released,
the glibc maintainer (perhaps after consulting knowledgeable people
to find out what is a good reference kernel) copies the include files
(perhaps removing the parts between #ifdef __KERNEL__ ... #endif)
from that kernel into /usr/include/linux, resolves possible name conflicts
and does other polishing as required by glibc.
After all, the kernel source is written for the kernel, and kernel
hackers do not have the glibc needs in mind. Moreover, the libc5 needs
may differ from the glibc needs.
This new setup is not worse than the present.
After all, programs are often run on machines with a kernel different
from the kernel under which they were compiled. It follows that the
kernel source that happened to be present at compilation time
should be irrelevant for the functioning of the program.
Even stronger: programs compiled on a libc5 system should function
on a glibc system and vice versa. Earlier this week, while preparing
the next util-linux release, I stumbled over the fact that the glibc
reboot() is incompatible with the libc5 reboot() in a way that makes
both completely unusable, and programs like shutdown and ctrlaltdel
now have to handcraft the system call. Unfortunate.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/