Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 22 Feb 2003 06:23:09 +0300
From: Solar Designer <>
Subject: Re: /usr/include/{linux,asm}

On Fri, Feb 21, 2003 at 04:19:39AM +0100, Maciek Pasternacki wrote:
> Solar Designer <> writes:
> > However, there're also valid reasons to want to build applications or
> > especially kernel modules with newer kernel headers.
> For me, if someone needs to rebuild an app which needs more than
> distribution gives, he should know what he's doing.


> > I personally prefer manual control over which kernel headers I use and
> > which kernel I run.  
> I see it like this: in /usr/include/linux I have the very same headers
> that were used to build glibc.  For most program I would need to
> compile it's enough.  When I need to use newer kernel functionality,
> I just add e.g. -I/usr/src/linux-current-version and gcc happily takes
> the new headers.

So you have a solution which works well for you with our current
setup. ;-)

> > Yes, we currently have these symlinks, but
> > /usr/src/linux doesn't have to match the running kernel (although that
> > is often convenient).
> Keeping old, unused kernel sources (probably cut down just to
> include/) in /usr/src/linux looks like a kludge.  Why not package
> these headers as a part of glibc (which they, de facto, are) and keep
> current kernel's source in /usr/src or in my home directory?

I'm not saying we won't do it.  I am considering it since I've seen
Red Hat make a similar move (although the way they've done it is rather
ugly: they have a separate .tar.bz2 with Linux 2.4.2 kernel headers
in glibc-kernheaders SRPM).

Yes, it is possible that our glibc builds will package the kernel
headers they used, in a glibc-kernel-headers "binary" subpackage.  Our
perl package already has something similar for *.ph's, although I am
unsure whether that is right (again, wouldn't it be better for some to
build the *.ph's whenever needed from the current kernel headers).

What I was saying is that such a setup, with /usr/include/{asm,linux}
being directories rather than symlinks, makes it less convenient for
some to build new stuff.


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.