[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20030220030312.GB26579@openwall.com>
Date: Thu, 20 Feb 2003 06:03:12 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: /usr/include/{linux,asm}
Hi,
I'm back from FOSDEM and the updated slides of our Owl presentation
as used at FOSDEM are now online:
http://www.openwall.com/presentations/
On Thu, Feb 20, 2003 at 02:26:13AM +0100, Maciek Pasternacki wrote:
> Jarno Huuskonen <Jarno.Huuskonen@....fi> writes:
>
> > On Sat, Feb 15, Maciek Pasternacki wrote:
> >> Why /usr/include/linux and /usr/include/asm in Owl are symlinks and
> >> not copies of headers against which glibc was built? Shouldn't these
> >> be part of glibc package, or at least be independent from whatever
> >> goes into /usr/src/linux?
> >
> > I think RedHat 6.2 uses those same symlinks (and if you're going to
> > install 2.4.x kernel, then 2.4.x include files get used).
Jarno is correct about the 6.2, but they (Red Hat) have changed it
since then. Note that I am saying "changed" rather than "corrected"
because this is a non-obvious choice to me.
> Yes, this is the problem. The includes in /usr/include/linux and
> /usr/include/asm should not match currently running kernel,
s/should not/don't have to/
> but should be the ones against which glibc was compiled.
For guaranteed-correct builds of purely-userspace applications,
without letting them use some functionality introduced with newer
kernels, yes.
However, there're also valid reasons to want to build applications or
especially kernel modules with newer kernel headers.
> If some struct
> definition changes under the feet, keeping binary compatibility but
> e.g. changing size, then it may break som glibc's routines which use
> the old size or some arcane cpp macros in glibc's headers.
I think Linus used a better example in the linux-kernel discussion
you've previously referred to (thanks!)
I personally prefer manual control over which kernel headers I use and
which kernel I run. Yes, we currently have these symlinks, but
/usr/src/linux doesn't have to match the running kernel (although that
is often convenient). It's only /boot/System.map (or one of its
alternate pathnames) and modules which should match the running
kernel.
In practice, it is usually safe to build applications against newer
Linux 2.2.x kernel headers than those glibc was built with. It should
be the same for different 2.4.x's. Mixing 2.2.x and 2.4.x is not so
safe, but even that is sometimes reasonable: currently, our glibc is
built against 2.2.x, but if you actually run 2.4.x and want to build
iptables, you have to build it against the 2.4.x kernel headers. And
it works, despite the version difference with the glibc build. If we
were to "hard-package" the kernel headers that glibc was built against,
doing such builds would become even more of a hack.
But you've brought up a valid problem that I'd like to deal with, -- I
am just not sure of how to better approach it such that we both ensure
correctness and don't reduce flexibility.
--
/sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
