[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20030222032309.GA2083@openwall.com>
Date: Sat, 22 Feb 2003 06:23:09 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: /usr/include/{linux,asm}
On Fri, Feb 21, 2003 at 04:19:39AM +0100, Maciek Pasternacki wrote:
> Solar Designer <solar@...nwall.com> 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.
True.
> > 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.
--
/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.
