[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#53379: libc6-dev has /usr/include/linux/



On Fri, Dec 24, 1999 at 04:22:47PM +0100, Miquel van Smoorenburg wrote:
> Absolutely not. There has been a lot of discussion on the kernel mailing
> list about this last week, and a lot of kernel developers (including
> Linus himself) think it's a GOOD thing that /usr/include/linux and
> /usr/include/asm are included with glibc. Read the archives.

It doesn't matter what I think -- if you read those archives yourself,
you'll see that I've been arguing for the opposite (and getting creamed
by it from every kernel developer who I respect).  Please convince Linus
Torvalds, Alan Cox, Ingo Molnar, and Ted T'So.  [And please read the
message from Linus which I appended to the bug report.]

They've been unanimous that that namespace should reflect the
currently running kernel, not the bast choice for a robust
interface.

And, *Debian* does not currently put the currently running
kernel's include files there -- we opt for a stable interface.

I'm aware that there's some significant work to be done here,
but most of it can be done rather trivially.. something like:

find . -type f |
	xargs egrep -l '#include.*<(linux|asm)/' |
	xargs perl -i~ -pe 's-(include\s+<)(linux|asm)(/.*>)-${1}gcc$2$3-'

then use /usr/include/gcclinux/ and /usr/include/gccasm/
in place of /usr/include/linux/ and /usr/include/asm/.

> Definitely not true. For building modules you can simply use
> -I/usr/src/linux-2.4.25/include.

Yes, I can.  However, for example, Ted T'So will not support
his kernel modules on distributions where /usr/include/linux/
and /usr/include/asm/ do not represent the currently running
kernel.

> >The recommendation for glibc is to use copies of whatever files it needs
> >in some other directories.
> 
> PLEASE don't try to "fix" this. Debian is about the only distro that
> actually gets this right. Don't break it, pretty please ....

Unfortunately, it's still broken, even in debian.

The thing that's broken is gcc *using* that namespace.  I agree that
gcc should be using "frozen" instances of the kernel includes.  But
they should be somewhere else.  

And, yeah, we should probably include something like the above perl
invocation to help fix up broken sources.

-- 
Raul


Reply to: