Red Hat Bugzilla – Bug 113792
impossible to build correctly non-core modules against 2.6 kernel
Last modified: 2015-01-04 17:04:16 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 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 them... How reproducible: Always 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
can you paste the exact commandline that is given to gcc ? (and what kind of makefiles are used)
I really do not know the command line. The thing works this way: make -C /lib/modules/..../build SUBDIRS=/home/svu/ndiswrapper/driver modules 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.
http://cvs.sourceforge.net/viewcvs.py/ndiswrapper/ndiswrapper/driver/Makefile?rev=1.14&view=auto
Same story with the latest fedora kernels. Still "kernel tainted"
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).
that is because it no longer exists in 2.6. There is /lib/modules/2.6.2-1.169.rootsmp/build/include/config/modversions.h but that has a different meaning.
Yes. So it is rather ndiswrapper bug, not yours. Sorry. It uses linux/modversions.h instead of config/modversions.h
I will try to change their sources and build again...
any module that includes linux/modversions.h is broken beyond belief, even in 2.4. Shrug.
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.
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?
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.
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.
See also here http://www.mail-archive.com/kbuild-devel@lists.sourceforge.net/msg02079.html
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).
It seems the latest kernel versions are ok in this regard now.