Checked the sources for a couple of other third party modules,
to see whether they compiled on gcc 2.95.x.
Only modules built outside the kernel source framework are
affected - e.g. tdfx_drm, emu10k1, the utah-glx old gart.
old gart is halted in favour of newagp, which is in the
kernel 2.3.x tree anyway. They never resolved it for gart,
since they didn't have to once newagp moved.
But - I looked at emu10k1, and it gets around it by explicitly overriding
the default include path to avoid the include-file wrappers that come with
gcc 2.9.5 - "gcc -I/usr/include" in the makefile.
which overrides the patches in /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/include/,
(which is read before /usr/include in the default incpath for gcc 2.95.2)
The reason the linux kernel build itself isn't affected is because its makefiles also
explicitly set gcc -I/usr/src/linux/include (or wherever the src happens to be),
which, of course, means that they're avoiding the wrappers too.
As an experiment, I overrode the explicit incpath setting, and, sure
enough, the kernel refused to compile.
There's more third-party module wrong-header related problems
on the linux-kernel mailing list - overview at:
Basically, currently the only way you can be sure your module is
compiling with the right headers for the kernel is to
This is usually gcc -I/usr/src/linux/include/, but part of the rant on
linux-kernel was that this is not guaranteed to use the headers
for the correct (running) kernel if you gcc -I/usr/include/ as emu10k1 does,
since, even if your distro symlinks /usr/include/linux to /usr/include/src/linux,
you may well have built your kernel elsewhere.
Of course, if you follow the normal kernel building guidelines
this won't happen (but the gcc 2.9.5 thing will still get you) - i.e.
source tree of currently running kernel in /usr/src/linux-x.x.x/
/usr/src/linux is a symlink to /usr/src/linux-x.x.x/
/usr/include/linux is a symlink to /usr/src/linux/include/linux
/usr/include/asm is a symlink to /usr/src/linux/include/asm
Then if you kernel source upgrade, you put the tree in /usr/src/linux-y.y.y/
and you only need to change 1 symlink. Of course, among others,
Debian have their own ideas about this whole thing, so
it was proposed for the kernel to generate a config.mk stub
that points to the include path used for kernel compilation, thus
ensuring third party module authors could fairly easily grab the
correct include path in their makefiles, like the current config.h
file that allows you to see the flags used in kernel compilation,
but config.mk has not been implemented to date, as far as I can tell.
A dependency on the order of the include path seems like sort of
a dodgy thing. :-(