From Bugzilla Helper: User-Agent: Mozilla/4.6 [en] (WinNT; I) Description of problem: I rebuilt the kernel specifying a 486 sa the processor. Then I booted the new kernel and tried to build the kernel again (with a few configuration changes.) The rwsem.c compilation blew up with undefined symbols. I traced the problem to a conflict between the logic in config.in and rhautoconf.h. Why are you checking /boot/kernel.h to determine the 'module'? You aught to just check the processor type specified in that particular configuration run! Version-Release number of selected component (if applicable): 2.4.9-21 patch How reproducible: Always Steps to Reproduce: 1.Build kernel for i486 processor. (Maybe other processors as well - I've only tried the 486) 2.Boot new kernel. 3.Build kernel again. Actual Results: Build failed with undefined symbols in rwsem.c compilation. Expected Results: Clean kernel build. Additional info: I believe the problem is in the rhautoconf.h header. There you pick the processor the current kernel was built for from the /boot/kernel.h file. You aught to be using the target CPU as designated in the .config file! 7.2 distribution with 2.4.9-21 kernel update.
Did you do a "make mrproper" before starting the build ?
No. I did a 'make clean' as described in the Documentation/kbuild /bug-list.txt file. This has worked consistently in previous versions of the kernel. Further, 'make mrproper' cleans out the .config files so you have to restart the configuration process from scratch rather than simply makeing changes to the previous configuration. If 'make mrproper' is required in this context, PLEASE make sure you explain why in the Documentation/kbuild/bug-list.txt file and the README file. The code in include/linux/rhconfig.h is seriously flawed. Normally there is a correlation between the contents of .config and the definition of symbols in autoconf.h (or some similar file). The way rhconfig.h is implemented, that correlation is not maintained and build errors can result. Further, it introduces a gratuitous dependency on the architecture of the system used to do the build. I can understand Bill Gates's desire to make everybody upgrade to the latest and greatest hardware -- he has a lot of Intel stock, but I thought Red Hat was a bit more immune to that particular disease.
see include/linux/rhconfig.h is only used if you don't rebuild your own kernel. Once you change the .config with one of the make <x/menu>config tools that ought to be overwritten/overruled. Normally the include file dependencies automatically take care of getting the includes right (esp make oldconfig/menuconfig/xconfig), however it appears that this sometimes doesn't happen (wrong clock??).
Wrong clock? Hm. Possible but very unlikely. Kernel build takes hours on a 486. I typically start one in the morning before I go to work or before I go to bed at night. However, one of the side problems was configuring the RTC. A couple builds didn't get it right so the time might have been way off when the system rebooted. Wouldn't that just make the problem worse? Wouldn't doing a 'make ... dep dep ...' have the same effect? Or a 'make ... dep clean dep ...' sequence. I've done the equivalent to that in order to capture the error logs from each step in the build. (There are a couple of cosmetic errors that I was going to document and put into the linux-kernel mailing list when I had a few spare hours. They're not Red Hat's problem.) I've since done an almost complete system reinstallation, including juggling the partition assignments. (Saved the ifcfg-eth* files and XF86... files from the previous incarnation. The X files need a lot of fiddling because of the ANCIENT video card...) I'm almost at the end of another cycle in this process. I can probably get the system functioning without a third rebuild this cycle, but I'll do that 3rd rebuild and let you know what happens after I've gotten the system functional again.
make mrproper is also needed