Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 113792 - impossible to build correctly non-core modules against 2.6 kernel
impossible to build correctly non-core modules against 2.6 kernel
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-01-17 21:55 EST by Sergey V. Udaltsov
Modified: 2015-01-04 17:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-26 19:20:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sergey V. Udaltsov 2004-01-17 21:55:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)

Description of problem:
Just downloaded the latest 2.6 kernel from rawhide, tried to build
ndiswrapper and slmodem against it. Found, resulting .ko modules do
not get __versions symbol, so kernel claims it is tainted when loading

How reproducible:

Steps to Reproduce:
1. Take the latest kernel 2.6 rpm from rawhide
2. Take ndiswrapper release from ndiswrapper.sf.net
3. Build it and install as described in the instruction
4. Try to load the module ndiswrapper.ko

Actual Results:  Error messages in the /var/log/messages
Comment 1 Arjan van de Ven 2004-01-18 06:58:24 EST
can you paste the exact commandline that is given to gcc ?
(and what kind of makefiles are used)
Comment 2 Sergey V. Udaltsov 2004-01-18 09:27:42 EST
I really do not know the command line. The thing works this way:

make -C /lib/modules/..../build SUBDIRS=/home/svu/ndiswrapper/driver

So it calls standard kernel Makefile pointing to the driver directory.
I do not know whether this is the right way to do or not.
Comment 4 Sergey V. Udaltsov 2004-02-13 18:22:32 EST
Same story with the latest fedora kernels. Still "kernel tainted"
Comment 5 Sergey V. Udaltsov 2004-02-18 09:42:08 EST
Actually, the first sub-problem found is that modversions.h is not in
/lib/modules/.../build/include/linux. I think it should be easy to fix
(and really must be fixed).
Comment 6 Arjan van de Ven 2004-02-18 09:44:07 EST
that is because it no longer exists in 2.6.
There is 

but that has a different meaning.
Comment 7 Sergey V. Udaltsov 2004-02-18 10:34:34 EST
Yes. So it is rather ndiswrapper bug, not yours. Sorry. It uses
linux/modversions.h instead of config/modversions.h
Comment 8 Sergey V. Udaltsov 2004-02-18 10:35:14 EST
I will try to change their sources and build again...
Comment 9 Arjan van de Ven 2004-02-18 10:36:09 EST
any module that includes linux/modversions.h is broken beyond belief,
even in 2.4. Shrug.
Comment 10 Sergey V. Udaltsov 2004-02-18 11:35:10 EST
Changed the configuration to config/modversions.h - still same story.
The MOST funny thing is that same sources/kernel work for other
people. I could believe it is my env - but really have no clue where
to look at.
Comment 11 Sergey V. Udaltsov 2004-02-18 12:00:13 EST
OK. I will put my questions straight: 
1. Is the version of struct_module required by the module ABI?
2. Is there any way to check (using objdump or something) whether the
version is there or not?
3. When at the build stage this version is determined?
Comment 12 Sergey V. Udaltsov 2004-02-19 05:19:10 EST
I do not know whether it makes sense or not. Any "good" kernel module
contains the symbol ____versions (in the segment __versions). But all
3rd party modules I built - do not contain it. Looking at the kernel
code, I think it causes my problem. The question is when this symbol
appears and how would I get it into the modules. I presume some
breakage of the build process.
Comment 13 Sergey V. Udaltsov 2004-02-29 17:25:12 EST
More info. The modpost program generates INCORRECT ndiswrapper.mod.c
file. This file does not contain ____versions array. This happens
because none of the standard symbols are resolved by the modpost
(which generates ndiswrapper.mod.c). Probably this happens because
modpost gets only one argument (ndiswrapper) and cannot resolve
characters in the kernel itself. Is there any way to teach modpost
about the symbols in the kernel core?

I reopen the bug because I'd consider this a bug in modpost - or in
the kernel build Makefiles.
Comment 14 Sergey V. Udaltsov 2004-02-29 18:25:10 EST
See also here
Comment 15 Sergey V. Udaltsov 2004-03-01 09:39:38 EST
Could the patch mentioned in the link above be used in Fedora please?
I think this is crucual for the 3rd party modules support (like
winmodems etc).
Comment 16 Sergey V. Udaltsov 2004-11-26 19:20:52 EST
It seems the latest kernel versions are ok in this regard now.

Note You need to log in before you can comment on or make changes to this bug.