Red Hat Bugzilla – Bug 38133
2.4.2-2 modules don't build in RH 7.1
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.4.2 i686) On a clean install of RH 7.1, kernel modules won't build with errors similar to: In file included from dummy.c:34: /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and nonhexadecimal /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and nonhexadecimal /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and nonhexadecimal /usr/src/linux-2.4/include/linux/module.h:173: parse error before `62dada05' If "linux/versions.h" is included in "dummy.c", the module will build. Same problem was reproduced in tulip driver. Reproducible: Always Steps to Reproduce: 1. Install RH 7.1 2. cd /usr/src/linux-2.4 3. make menuconfig 4. set tulip and dummy network drivers to be modules 5. save config 6. make dep ; make modules 7. note errors Actual Results: On a clean install of RH 7.1, kernel modules won't build with errors similar to: In file included from dummy.c:34: /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and nonhexadecimal /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and nonhexadecimal /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and nonhexadecimal /usr/src/linux-2.4/include/linux/module.h:173: parse error before `62dada05' If "linux/versions.h" is included in "dummy.c", the module will build. Same problem was reproduced in tulip driver. Expected Results: Modules should build without errors. A clean download of linux-2.4.2 builds fine.
The default install allows external modules to be built against the source. If you do things with make menuconfig, you should first load the configfile for the kernel you are actually running, so it _might_ work. But if you change the config, you should recompile the entire kernel; Linux in general does not allow 1 extra module to be selected and then loaded. (Yes it works for a lot of drivers, but not nearly for all).
*** Bug 38134 has been marked as a duplicate of this bug. ***
The steps I gave only show the module building portion. In my own scenario, I did build the kernel before building the modules. The modules do NOT build. The problem seems to be with rhconfig.h: Many drivers don't include version.h early enough to avoid compile-time errors. When I added version.h to the offending modules, everything built fine. However, this is not an adequate solution for the vast majority of people who don't know anything about building the kernel.
If you change the config more than trivially, you MUST do "make mrproper" first. The makefile-dependencies of the 2.4 kernel are not quite complete enough to get this right for all but the simplest changes.
"make mrproper" doesn't do anything on a clean install of RH 7.1. This is the FIRST kernel build I am talking about here. I just reinstalled RH 7.1 (again) and I got the same behavior with the very first build of the kernel.
I have encountered the same build problem after doing: make config - no changes to config ( but may not match current kernel ) make dep make bzImage make install make modules Get error ..... Only other piece of info is that I am using the tulip module as well.
This bug is also reproduced this way: install kernel-source-2.4.2-2.i386.rpm over a vanilla redhat-7.1 (athlon) cd /usr/src/linux-2.4/ cp config/kernel-2.4.2-2.athlon.config .config (or use menuconfig's option to load a config file) make dep clean make bzImage make modules # fails on the first module eni.c The only workaround I found to recompile redhat's linux kernel for now is to install the source rpm kernel-2.4.2-2.src.rpm, and perform the prep steps to get all the patches applied (cd to /usr/src/redhat/SPECS/ and rpm -bp kernelxxx.spec). Then cd to /usr/src/redhat/BUILD/kernel-xxx/linux/ and do as usual (or copy the source tree to /usr/src).
When can we expect a compileable kernel-source. I use RedHat in a business environment and must have the ability to change the default kernel to meet my business needs.
The source IS compilable. I've done so a few times. Just be VERY sure you use "make mrproper" before doing anything else.
Maybe you haven't been reading this bug closely. After a clean install of Red Hat 7.1, if you set the dummy network device and the Tulip driver to be modules (these are two that I know are broken), run "make dep", run "make bzImage", run "make modules", and you'll see that the Tulip and dummy modules WILL NOT BUILD. What is "make mrproper" going to do on a clean install? Plus, IT DOESN'T WORK ANYWAY. The problem is with linux/rhconfig.h. Why can't you just fix it? I've done so, but I shouldn't HAVE to do this. I've got better things to do than debug kernel releases from other vendors.
I too am having this problem. Steps taken: 1. Install RH 7.1 FROM SCRATCH on a clean, freshly formatted partition. 2. Copy /usr/src/linux-2.4.2/configs/kernel-2.4.2-i586.config to /usr/src/linux-2.4.2/.config 3. Run make menuconfig, check over options, save config (No changes made) (Did not run make mrproper since this was a clean, never-touched install. Other observers report that this does not help in any case.) 4. Run make dep - no errors 5. Run make bzImage - no errors 6. Run make modules - errors same as previously reported on compiling /usr/src/linux-2.4.2/drivers/atm/eni.c In file included from eni.c:6: /usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and not hexadecimal etc
scotty@a-concepts.com: make mrproper _is_ needed on a fresh install. The reason for this is that a fresh install allows you to compile external modules against the source (like vmware or nvidia). This means that a fresh install is not clean regarding symbol versions; once you do a make mrproper the tree is clean and the compile works. (well, it does for me. I've tried this several times in the last days now)
Ok, I went and tried "make mrproper" before making the modules, and it worked. I thought I had tried this before to no avail, but apparently not. However, I still feel that a clean install of the kernel source should not require this as it should already be clean.
I confirm that running make mrproper indeed corrects this problem. This conflicts slightly with the standard kernel documentation, so for those who may be confused, here are the steps (Do not skip any!): 1. cd /usr/src/linux-2.4.2 2. make mrproper 3. copy the appropriate config file for your architecture from the configs directory to .config. (For example: cp config/kernel-2.4.2-i586.config .config 4. make menuconfig (or make config or make xconfig) and save the configuration on exit 5. make dep 6. make bzImage 7. make modules 8. make modules_install You will also need to install the kernel (try the /sbin/installkernel script, but be sure to edit /etc/lilo.conf first)
IMPORTANT: If you are rebuilding a working kernel or modifying an existing kernel before you run mrproper MAKE A COPY of .config. mrproper will erase .config, if you don't have a copy of the configuration you will start from scratch!
Same problem as above (nondigits in nonhex...), noticed it with a few modules other than tulip, dummy, running make mrproper fixed problem however.
I came here after searching for this type of problem, after a Red Hat employee told me to come here. I too have this problem after a clean Red Hat 7.1 install, and after trying to run make modules for the rtc.c module. And make mrproper did fix the problem. However this shouldn't have to happen on a clean install. Is this case still open?
Created attachment 26453 [details] make modules results (without make mrproper)
It can be closed as far as I am concerned.
Missed closing this before.