2.95.3 destruction in Linux header

[Stephen L Moshier]

> I'm not entirely sure yet what's going on, but I believe the problem is
> that you're compiling a piece of kernel code, but not using
> "-I /path-to-linux/include".  This means when one of the kernel headers
> tries to include <asm/posix_types.h>, it doesn't use the one from the
> kernel tree, but rather takes gcc's fixincluded one.  This in turn uses
> features.h, which is a libc header file.  This sort of mixup can lead to
> strange effects.
> 
> I think you need to set the include path properly for this to work.


Well, I agree that this is what is happening, but I don't agree
that it ought to be happening.  I'm merely trying to install a
device driver that builds fine with earlier versions of gcc.
This file,
   /usr/lib/gcc-lib/i486-linux/2.95.3/include/asm/posix_types.h
breaks a program that used to work.  Moreover, this file causes a
general header file system meltdown.  Surely it is a bad design, to
have header files that self-destruct.  It would be a bad policy to say
it is OK to design headers so that they self-destruct.

You seem to be telling me to use a workaround for buggy header files,
but this IS the buggy header file; why not fix it?  The device driver
program explicitly includes a total of 16 other linux and asm headers
and it does not require the workaround until this buggy header is
used.

This header needs to be fixed.  It should be given some kind of
protection against conflicts with the linux kernel definitions.  Are
the replacement definitions needed when compiling kernel code?  Does
the kernel try to use the broken glibc code?  If not, then maybe just
surrounding with #ifndef __KERNEL__ would be enough to fix it.