Bug 59308 - Undefined symbols in rwsem the 2nd time kernel is rebuilt after selecting i486 as the processor.
Summary: Undefined symbols in rwsem the 2nd time kernel is rebuilt after selecting i48...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-04 23:41 UTC by Max TenEyck Woodbury
Modified: 2007-04-18 16:39 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-08 01:07:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Max TenEyck Woodbury 2002-02-04 23:41:22 UTC
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:

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.

Comment 1 Arjan van de Ven 2002-02-11 16:08:42 UTC
Did you do a "make mrproper" before starting the build ?

Comment 2 Max TenEyck Woodbury 2002-02-11 19:11:34 UTC
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

Comment 3 Arjan van de Ven 2002-02-11 19:18:57 UTC
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??).

Comment 4 Max TenEyck Woodbury 2002-02-11 20:54:08 UTC
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.

Comment 5 Alan Cox 2003-06-08 01:07:06 UTC
make mrproper is also needed

Note You need to log in before you can comment on or make changes to this bug.