Red Hat Bugzilla – Bug 59308
Undefined symbols in rwsem the 2nd time kernel is rebuilt after selecting i486 as the processor.
Last modified: 2007-04-18 12:39:45 EDT
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
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.
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
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
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