Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] glibc 2.5 going into test?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] glibc 2.5 going into test?
  • Date: Wed, 13 Jun 2007 22:35:54 +0200

On Wed, Jun 13, 2007 at 09:52:44PM +0200, Thomas Orgis wrote:
> Am Wed, 13 Jun 2007 20:11:28 +0200
> schrieb Arwed von Merkatz <v.merkatz AT gmx.net>:
>
> > > Have you looked into moving the kernel headers outside of glibc, or have
> > > glibc using whatever is in /usr/src/linux to generate its headers,
> > [...]
> >
> > My plan was to use the headers of the current kernel on the system as
> > long as they can found (can't always find them for custom kernels) and
> > otherwise some pre-tarballed ones.
>
> I'd prefer a tested set of headers before finding out much later that
> stuff doesn't compile with my glibc / linux headers.
> I faintly remember a LFS system I had where I just (tried to) used the
> plain linux 2.6 headers... some apps didn't like to compile with these...
>
> What's the official state of the glibc-linux-headers mess? Are the plain
> headers considered "safe" nowadays? Well, I read that Arwed had to patch
> them already...

The official state as far as I can tell is that no one really cares much
...
I looked at some other distro kernel headers packages, and they're
mostly current vanilla headers with a few changes. Overall, the kernel
headers are quite sane now. I didn't actually have to patch any headers
so far, I patched two apps that preferred to use kernel system calls
directly instead of using glibc (util-linux and net-tools). Both were
tiny patches that just copied system call definitions in there.

I can see the point of a tested set of headers though, so using a known
tarball of (current) kernel headers to be installed by glibc is probably
a more predictable solution than just using whatever is currently on the
system.
Fact is that there already are programs that don't work correctly with
the ancient kernel headers we currently install, so after a bit more
widespread testing, going for current vanilla headers is probably safer
than staying with what we have now.

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page