[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878ywacoc4.fsf@lizard.ds.pg.gda.pl>
Date: Fri, 21 Feb 2003 04:19:39 +0100
From: Maciek Pasternacki <maciekp@...hy.fnord.org>
To: owl-users@...ts.openwall.com
Subject: Re: /usr/include/{linux,asm}
Solar Designer <solar@...nwall.com> writes:
>> 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/
Right. Maybe I should put this disclaimer at the beginning of this
thread -- sorry for my English.
>> 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.
For me, if someone needs to rebuild an app which needs more than
distribution gives, he should know what he's doing. Specifying newer
kernel's headers is just one -I for gcc.
> 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.
> 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?
> 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.
Well, for me symlinking /usr/include/linux is quite an ugly hack, and
if I compile iptables, which I know is just for linux-2.4, and I know
it is unsupported by Owl, I am prepared to give iptables location of
kernel headers by hand.
*clickety click* http://www.netfilter.org/...
Well, iptables-1.2.7a INSTALL says to specify kernel dir (not only
headers) manually:
#v+
1) Next, make the package.
% make KERNEL_DIR=<<where-you-built-your-kernel>>
2) Finally, you need to to install the shared libraries, and the binary:
# make install KERNEL_DIR=<<where-you-built-your-kernel>>
#v-
By default it tries to use /usr/src/linux, but when I try to compile
it with linux-2.2 there, I get something like this:
#v+
leeloo!japhy:~/iptables-1.2.7a$ make
Making dependencies: please wait...
Something wrong... deleting dependencies.
Please try `make KERNEL_DIR=path-to-correct-kernel'.
#v-
I think other programs which need specific version of kernel headers
also check them; except, maybe, NVidia's drivers, but number of people
needing to compile NVidia's drivers on Owl is negligible.
--
__ Maciek Pasternacki <maciekp@...hy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...so I talked about conscience, and I talked about pain,
,|{-}|}| }\/ and he looked out of window, and it started to rain, and
\/ |____/ I thought, maybe - I've already gone crazy... } ( Fish ) -><-
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.
