* Re: [gentoo-dev] linux-headers ebuild version.
@ 2003-06-20 21:04 99% ` Adam Trilling
0 siblings, 0 replies; 1+ results
From: Adam Trilling @ 2003-06-20 21:04 UTC (permalink / raw
To: gentoo-dev
(first time poster, don't flame me please :) )
There has been some discussion of this on lkml recently, and also on
lfs-dev. I unfortunately haven't been following either discussion as
closely as I should, but here's the gist of what I understand:
The longstanding belief is that the kernel headers in /usr/include should
be the ones that glibc was compiled against. This makes sense, since
glibc is putting it's headers in /usr/include, and it keeps all of
/usr/include consistent with itself.
However, as the kernel changes, compiling glibc against different sets of
kernel headers results in different (inconsistent) glibcs. This brings up
the need for a standard kernel API. The bits I picked up from lkml and
lfs-dev were that the kernel guys wanted a "sanitized" set of headers that
would theoretically work with any glibc and any kernel, and there was some
vehement disagreement over exactly how to develop these "sanitized"
headers.
Part of the problem is broken packages. Based on the idea of putting the
headers used for glibc in /usr/include, any package that needs kernel
headers in userspace should use /usr/include/linux, and drivers that
aren't included in the kernel should use the running kernel's headers
(/lib/modules/`uname -r`/build/include).
Now, what does this have to do with gentoo? Well, first of all, I assume
those in charge will be paying attention to kernel and glibc development
to see what becomes of the header sanitization. Second, maybe we can
force ebuilds to use the proper set of headers somehow? Like maybe
setting a flag in the ebuild that temporarily symlinks
/usr/include/{linux,asm} to /lib/modules/`uname -r`/build/include?
adam
On Fri, 20 Jun 2003, David Nielsen wrote:
> I had countless problems getting stuff to compile against 2.5 because of
> 2.4 headers being present in /usr/lib - this madness has to end, is
> there no sane solution to this crap, basically we risk breaking
> something at near random when we upgrade the kernel just because some
> header changed and some program makes an assumption that is wrong like a
> struct that has changed - right?
>
> we need a sane way to work around this - I remember Martin Schlemmer
> once proposing a kernel API to make sure we always had a sane way of
> working with the kernel without including kernel headers in userspace
> which is the cause of many a problem.
>
> - Lovechild
>
> On Sat, 2003-06-21 at 00:40, Svyatogor wrote:
> > On Friday 20 June 2003 19:25, Martin Schlemmer wrote:
> > >
> > > Anyhow, in general in Gentoo, if you compile something like iptable,
> > > nvidia-kernel, alsa, etc, it use the kernel headers in /usr/src/linux,
> > > as it is easier to manage (say you are running kernel from livecd,
> > > but want to compile whatever for your kernel that you will be
> > > booting ...).
> > Exactly, so it shouldn't be installing the headers in /usr/include/linux,
> > which is what linux-headers does.
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
Adam Trilling
agt10@columbia.edu
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2003-06-20 20:20 [gentoo-dev] linux-headers ebuild version Svyatogor
2003-06-20 18:03 ` Chris PeBenito
2003-06-20 19:25 ` Martin Schlemmer
2003-06-20 22:40 ` Svyatogor
2003-06-20 20:34 ` David Nielsen
2003-06-20 21:04 99% ` Adam Trilling
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox