[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



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: