Bug 113792
Summary: | impossible to build correctly non-core modules against 2.6 kernel | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Sergey V. Udaltsov <sergey_udaltsov> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | kajtzu, pfrields |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-11-27 00:20:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Sergey V. Udaltsov
2004-01-18 02:55:53 UTC
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. 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. 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. |