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

Re: problems when building a kernel module 'out of the box'



On Thu, Nov 20, 2003 at 02:47:19PM -0000, Mike at VirginNet wrote:
> When I try to install a newly built module, I get the following error :-
> 
>     modulename.o: kernel-module version mismatch
>         modulename.o was compiled for kernel version 2.4.18
>         while this kernel is version 2.4.18-bf2.4
> 
> The build of the module looks like :-
> 
>     gcc -D__KERNEL__ -DMODULE -DMODVERSIONS -include /usr/src/kernel-headers-2.4.18-bf2.4/include/linux/modversions.h -Wall -Wstrict-prototypes -O2 -m486 -c modulename.c -I/usr/src/kernel-source-2.4.18/include
> 
> 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 -Wstrict-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.

> 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.

  * 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.

  * 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.

> Am i likely to need to do something similar here?  And can I use the
> RH9 RPMs to achieve it on Debian, or is that sacrilege/doomed to
> failure?

Sounds like a bad idea.


By the way, please don't direct questions like this to debian-release in
future; this list is for coordination and management of Debian releases.
I've set followups to debian-user, which is more appropriate.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: