In <Pine.LNX.3.96.1000625204722.14670D-100000@tarot.mentasm.org> ferret@phonewave.net (ferret@phonewave.net) wrote:
> And I thought this was resolved some years ago... But...
It does NOT resolved :-( General idea of resolution was introduced with
GLibC 2: NO kernel headers are needed for userspace programs. Instead
GLibC must use kernel headers as "raw data" in build time and will include
all extracted information in *bits* subdirectory. Unfortunatelly last time
I checked GLibC's headers STILL included some kernel headers. Not sure why
it's not fixed yet - it does not look like very hard task (boring - perhaps,
but not THAT hard). Thus GLibC STILL suffers from such problems. It's not
kernel problem anyway.
> <RFC>
> Which kernel's header files should go into /usr/include/linux for the C
> library's use?
> So far we have seen two options:
> 0) The kernel headers the C library was compiled against.
> 1) The kernel headers from the "current" kernel.
> And we have one major GNU/Linux distribution doing each: Debian using
> option 0, and Red Hat using option 1.
> Which option is the best, and why?
> </RFC>
Both have pro- and contra- :-/
> <IMO>
> I reccomend option 0:
> For applications, compiling with the same headers the C library was
> compiled with will prevent a possible point of failure.
Apllications should NEVER use kernel headers. Period.
> I'm going completely from memory here, but I believe Linus used this type
> of example around two or so years ago when complaining about Red Hat using
> symlinks into the kernel source.
Linus camplained about whole idioticy of direct linux kernels usage in
userspace programs.
> Somewhere in your headers you have a struct foo { }; which is part of
> kernel subsystem bar.
> Your C library is compiled against kernel version N.
> Now come along and upgrade to kernel verson P, where our struct foo { };
> has several extra fields in it for some new subfeature in subsystem bar.
> I do not remember the exact technical details of the argument, but the
> gist was that anything using foo/bar has an extra point of subtle
> breakage.
It's trivial: if struct foo is passed around in GLibC it'll use sizeof(old foo)
while application (using kernel headers) will use sizeof(new foo) thus
overflowing internal GLibC's buffers.
> Also, con to option 1:
> In a case like my system I use to compile kernels for all different
> machines, which of these is the current kernel? I could see where I might
> end up with a program compiling for Alpha might try to compile against
> Sparc kernel headers, for instance.
> i believe the cross-compiling packages use static kernel headers per arch.
> </IMO>
In fact right aswers is 2) :
there should be NO linux (and asm) subdirectories with copies of actual
kernel headers (or symlinks to actual kernel headers) in /usr/include
Ability to use such system was stated gold of GLibC 2. It's pity that you
still can not do this :-(
> On Sun, 25 Jun 2000 ferret@phonewave.net wrote:
>>
>>
>> On Sun, 25 Jun 2000, Matthew Vanecek wrote:
>>
>> > Steve Dodd wrote:
>> > >
>> > > On Sat, Jun 24, 2000 at 01:04:47PM +0100, Adam Sampson wrote:
>> > >
>> > > > Also, what's the official stance on what headers should be in
>> > > > /usr/include/linux? The glibc 2.1.3 documentation says that
>> > > > /usr/include/linux and usr/include/asm should be symlinks into the source
>> > > > tree, but this hasn't been true for a long time now. Where should we get
>> > > > the "new" headers from?
>> > >
>> > > $ dpkg -S /usr/include/linux
>> > > libc6-dev: /usr/include/linux
>> > >
>> > > IOW, your libc headers package should include the kernel headers it was
>> > > built against, I think.
>> >
>> > Are we trying to have a strict demarcation between Linux kernel headers,
>> > and glibc headers? So that /usr/included/linux should come from glibc?
>> > My /usr/include/asm and /usr/include/linux have been links into the
>> > source tree for the last 5 years. Whenever someone complains about
>> > missing headers, the de facto answer is "Do you have these symlinks?".
>> > Look it up in the archives of almost any linux help list or newsgroup.
>> > The simple fact of the matter is that for most people, the current
>> > source tree contains the directories to which the links in /usr/include
>> > point. The leaders of Linux kernel development may think they know
>> > better, but according to common convention, and to glibc documentation,
>> > /usr/include/linux, /usr/include/asm, etc., point to the current source
>> > tree.
>> [major snippage]
>>
>> What is considered the "current" source tree?
>>
>> Sometimes I use one machine to compile kernels and software for other
>> machines, and I keep several different kernel versions around, under
>> /usr/src/linux-<kernel version>. I even occationally cross-compile for
>> Sparc linux.
>>
>> Perhaps this needs to become a kernel/glibc RFC?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:08 EST