> On Fri, Dec 15, 2000 at 12:14:04AM +0000, Miquel van Smoorenburg wrote:
> It's the version that's in cvs, I just did an cvs update. It's
> been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This subject has come up quite a few times in the past
couple of weeks on the scyld (eepro/tulip) mailing lists.
Essentially, whatever solution is implemented MUST ensure :
1 - glibc will work properly (the headers in /usr/include/* don't
change in an incompatible manner)
2 - programs that need to compile against the current kernel MUST
be able to do so in a quasi-predictable manner.
Here's some suggestions (feel free to hack this to pieces, but please
don't let this fall to the side with everyone doing it differently!
we need consensus! :)
- /usr/include/[linux|asm] will be directories, not symlinks, and
their content will be the headers that glibc was compiled against.
- /usr/include/kernel will be a symlink to the target kernel headers.
i.e. /usr/src/linux/include for most of us.
This way, anything that needs to use the 'default' methods of accessing
these headers will be able to function as usual, and anyone who needs
to access the specific kernel headers can simply do -I/usr/include/kernel
I know that for my projects this is essentially what I do : I make sure that
all of my separate-from-kernel compiling that needs to be done that depends
on the kernel gets recompiled every time i change the kernel,
but I only change /usr/include/linux when I recompile glibc.
We really need a documented way to deal with this!
It's getting silly the number of questions that people ask!
-- Dana Lacoste Linux Developer Peregrine Systems- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 15 2000 - 21:00:32 EST