1 |
(first time poster, don't flame me please :) ) |
2 |
|
3 |
There has been some discussion of this on lkml recently, and also on |
4 |
lfs-dev. I unfortunately haven't been following either discussion as |
5 |
closely as I should, but here's the gist of what I understand: |
6 |
|
7 |
The longstanding belief is that the kernel headers in /usr/include should |
8 |
be the ones that glibc was compiled against. This makes sense, since |
9 |
glibc is putting it's headers in /usr/include, and it keeps all of |
10 |
/usr/include consistent with itself. |
11 |
|
12 |
However, as the kernel changes, compiling glibc against different sets of |
13 |
kernel headers results in different (inconsistent) glibcs. This brings up |
14 |
the need for a standard kernel API. The bits I picked up from lkml and |
15 |
lfs-dev were that the kernel guys wanted a "sanitized" set of headers that |
16 |
would theoretically work with any glibc and any kernel, and there was some |
17 |
vehement disagreement over exactly how to develop these "sanitized" |
18 |
headers. |
19 |
|
20 |
Part of the problem is broken packages. Based on the idea of putting the |
21 |
headers used for glibc in /usr/include, any package that needs kernel |
22 |
headers in userspace should use /usr/include/linux, and drivers that |
23 |
aren't included in the kernel should use the running kernel's headers |
24 |
(/lib/modules/`uname -r`/build/include). |
25 |
|
26 |
Now, what does this have to do with gentoo? Well, first of all, I assume |
27 |
those in charge will be paying attention to kernel and glibc development |
28 |
to see what becomes of the header sanitization. Second, maybe we can |
29 |
force ebuilds to use the proper set of headers somehow? Like maybe |
30 |
setting a flag in the ebuild that temporarily symlinks |
31 |
/usr/include/{linux,asm} to /lib/modules/`uname -r`/build/include? |
32 |
|
33 |
adam |
34 |
|
35 |
On Fri, 20 Jun 2003, David Nielsen wrote: |
36 |
|
37 |
> I had countless problems getting stuff to compile against 2.5 because of |
38 |
> 2.4 headers being present in /usr/lib - this madness has to end, is |
39 |
> there no sane solution to this crap, basically we risk breaking |
40 |
> something at near random when we upgrade the kernel just because some |
41 |
> header changed and some program makes an assumption that is wrong like a |
42 |
> struct that has changed - right? |
43 |
> |
44 |
> we need a sane way to work around this - I remember Martin Schlemmer |
45 |
> once proposing a kernel API to make sure we always had a sane way of |
46 |
> working with the kernel without including kernel headers in userspace |
47 |
> which is the cause of many a problem. |
48 |
> |
49 |
> - Lovechild |
50 |
> |
51 |
> On Sat, 2003-06-21 at 00:40, Svyatogor wrote: |
52 |
> > On Friday 20 June 2003 19:25, Martin Schlemmer wrote: |
53 |
> > > |
54 |
> > > Anyhow, in general in Gentoo, if you compile something like iptable, |
55 |
> > > nvidia-kernel, alsa, etc, it use the kernel headers in /usr/src/linux, |
56 |
> > > as it is easier to manage (say you are running kernel from livecd, |
57 |
> > > but want to compile whatever for your kernel that you will be |
58 |
> > > booting ...). |
59 |
> > Exactly, so it shouldn't be installing the headers in /usr/include/linux, |
60 |
> > which is what linux-headers does. |
61 |
> |
62 |
> |
63 |
> -- |
64 |
> gentoo-dev@g.o mailing list |
65 |
> |
66 |
|
67 |
|
68 |
Adam Trilling |
69 |
agt10@××××××××.edu |
70 |
|
71 |
-- |
72 |
gentoo-dev@g.o mailing list |