>
> Ok, this isn't entirely a kernel issue, but here's the problem:
> if you include linux/types.h, glibc totally barfs...
>
> Question: which should I protect by what #define/#ifndef pairs?
One of the best ways I've seen to handle this is to #define
__STRICT_KERNEL_NAMES at the start of each source file; this keeps most of
the name collisions from happening. However, #include <linux/socket.h>
causes a hard conflict on (I believe) all the data types at the start of
the file.
> Right now, I'm checking gnu/types.h for predefines of __NFDBITS,
> or __FDMASK etc. What would be the best way to minimize conflict?
>
> Also, why are programs including linux/*? That should be reserved if they
> directly interface with the kernel, correct? modules, stuff like procps
> perhaps? Is it stupid programmers or was it simply because standard
> libc /includes used current linux source for types.h?
I'm not sure what the problem is, either; it seems that a lot more
programs which were designed to be portable use the 'proper' (at least
under glibc2) include files than programs which were written specifically
for Linux.
At any rate, it makes running glibc2 awfully hard; right now,
linux-nfs-0.4.21 (well, that's 2.1, but it's a good example anyway) has
bad collisions that cause various parse errors and other things that
prevent it from compiling (even after simple fixes and correction of
some include directives).
Has anyone else made progress, or does anyone else want to try making
patches for linux-nfs-0.4.21 that will let it compile with glibc?
Michael Poole