In article <[EMAIL PROTECTED]> you wrote:
> On Wed, 15 Dec 1999, Hamish Moffatt wrote:
>> On Wed, Dec 15, 1999 at 02:24:43AM +0000, Jorge Matias wrote:
>> > Probably you don't have symbolic links:
>> > /usr/include/asm to /usr/src/linux/include/asm-i386
>> > /usr/include/linux to /usr/src/linux/include/linux
>>
>> And be glad that you don't, because you shouldn't.
> Oh? Really? Then how come a _LOT_ of my glibc headers include <linux/*.h>
> and/or <asm/*.h> ? Is glibc supposed to replace all those some day (good
> luck!) ?
Speaking philosophically, any time a user-space program has to have access to
kernel .h files instead of using a published interface to the kernel, it's a
sign that something is "broken".
>From a practical standpoint, it is true that in the current state of the
kernel, various programs (in particular some very interesting independently-
distributed kernel modules) need to access kernel .h files. The best way to
handle this is to use a '-I' option to the compiler to put the tree of kernel
includes ahead of /usr/include.
I'll append the Debian /usr/share/doc/libc6/FAQ.Debian.gz contents that talk
about this. My understanding is that even Linus agrees this is the right way
to do things, but he didn't consider the issue significant enough to push
with the various other distributions that use symlinks.
Bdale, N3EUA
Q1: Why does the Debian libc6-dev package create /usr/include/linux and
/usr/include/asm directories containing header files from a specific
kernel, instead of using the "established" convention of making those
directories into symlinks pointing to the currently installed kernel?
A1: Occasionally, changes in the kernel headers cause problems with
the compilation of libc and of programs that use libc. To ensure that
users are not affected by these problems, we configure libc to use the
headers from a kernel that is known to work with libc and the programs
that depend on stable kernel headers.
Q2: What if I want to compile a program that needs a feature from a
later kernel than is used by libc?
A2: In practice, most programs will not have this problem. However,
depending on the scope of the problem you have several options available:
If the situation is one like "kernel driver development", where all use
of the machine for development is expected to be against a different set
of kernel headers than are supplied with the "stock" libc6-dev, rebuilding
the glibc packages against that particular kernel will create a full set of
libc6 packages that are "compliant" with the new kernel. All development
done on machines with these packages installed will be done against the
new kernel. To build libc6-dev against your particular kernel, export the
environment variable ksource, set to the path to that particular kernel and
build the package.
If you want this new glibc package to stick against further upgrades, simply
use dselect and place the packages on HOLD. This will keep them from being
upgraded against your wishes.
If there is just one particular program/package that needs different headers,
and your kernel of choice is installed in the usual place, you can use the
-I/usr/src/linux/include option on the gcc command line, when compiling that
specific program.
