On Wed, Dec 15, 1999 at 10:25:03PM +0200, Tomi Manninen OH2BNS 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!) ?
>
> Anyway a small correction: /usr/include/asm should point to
> /usr/src/linux/include/asm not asm-i386.
Including <linux/*.h> and <asm/*.h> is fine. The glibc kernel headers
include the files in /usr/include/linux and /usr/include/asm directly;
they are not links into /usr/src/linux (there is no need).
If you need the exact .h files for the current kernel, you should
get them out of /usr/src/linux/include directly using -I. On Debian
at least, /usr/include contains the header files provided by glibc,
and not the current kernel versions. Craig's ax25-tools sources cope
just fine with this.
I've included Debian's FAQ on the subject below.
Hamish
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.
--
Hamish Moffatt Mobile: +61 412 011 176 [EMAIL PROTECTED]
Rising Software Australia Pty. Ltd. http://www.risingsoftware.com/
Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA: 1 888 667 7839
