Re: problems when building a kernel module 'out of the box'
Hi Colin,
> > The seemingly obvious would be to change this to :-
> >
> > gcc -D__KERNEL__ -DMODULE -DMODVERSIONS -include
/usr/src/kernel-headers-2.4.18-bf2.4/include/linux/modversions.h -Wall -Wstr
ict-prototypes -O2 -m486 -c
modulename.c -I/usr/src/kernel-source-2.4.18-bf2.4/include
> >
> > ...only there isn't any kernel-source-2.4.18-bf2.4 on the issue DVD.
> > How am I supposed to proceed?
>
> I think you want kernel-headers-2.4.18-bf2.4. There's such a package in
> stable.
OK, that worked. Thanks.
> > BTW It seems from my experiences that Linux release systems are
> > generally buggy! I had a very similar experience with Red Hat 9 a
> > couple of months ago, and in that instance the recommendation was to
> > install the latest version of the kernel, plus the latest version of
> > the kernel source, and that would clear things up. In the event it
> > caused a build error which I had to find my way around by creating
> > links in the /usr source and include trees, specifically for a 'linux'
> > directory to be a link to a specific linux directory and for an 'asm'
> > directory to be a link to a specific asm includes directory.
>
> Making /usr/include/linux and /usr/include/asm symlinks is Very Bad.
> There are three issues involved:
>
> * glibc needs to have a set of kernel headers for its own use, which
> live in /usr/include/linux and /usr/include/asm. These MUST match
> the kernel version against which glibc was compiled, and you
> shouldn't try to make them match the kernel version you're running.
So you're saying that the binary GCC I'm running, requires the very
mainstream-sounding path /usr/include/linux to be dedicated for its own use,
to refer to *while its executing*, and yet my own need for access to the
headers relevant to all of my actual work here, need to be stuck off on some
backwater pathname like /usr/src/kernel-headers-2.4.xxx?
If an executable must necessarily have access to parts of its own
constituent source (and I've almost never seen an inescapable need for this,
in a good long career) it would have been more elegant for the binary GCC to
have its own specific headers installed in its own dedicated area, perhaps
called /usr/src/gcc-version-XXX/include/linux. Then the developer's access
to kernel headers could be along the obvious /usr/include/linux path. OK,
so that's not how it's been done. More's the pity.
> * Third-party kernel modules need to build against the headers from
> the kernel you're running. Those can live anywhere; modern kernel
> packages set a /lib/modules/`uname -r`/build symlink so that modules
> can find them more easily, but you do need to have the appropriate
> kernel-headers package installed.
Useful background info.
> * Normal user programs must not include anything in /usr/include/linux
> or /usr/include/asm directly, since those headers are generally not
> guaranteed to be suitable for use from userspace directly, only via
> glibc. If need be, programs should copy the values of the constants
> they need, which isn't very clean but is necessary.
I didn't need to be told any of that! I'm not talking about
/usr/include/asm. What I needed in RH9 was for my build directory to
contain a symlink to the hardware-specific asm-xxxx directory in the
/usr/include tree. It has now transpired that this link is unnecessary when
I point the compiler at the RH9 equivalent of
/usr/src/kernel-headers-2.4.xxx. Again, thanks.
Cheers,
Mike
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/03
Reply to: