Red Hat Bugzilla – Bug 64814
conventional kernel build fails
Last modified: 2007-04-18 12:42:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313
Description of problem:
see attached report
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.method is described in attached report
Actual Results: linker errors leading to a make failure
Expected Results: new kernel has been built
I've been using this technique to build RHL kernels for more than 3 years.
(Unless I've made some silly mistake.)
Created attachment 57044 [details]
problem report, as submitted to Valhalla mailing list
I read your report. I am not sure if it will help, but you could try starting
with no .config after doing a make mrproper. You should then be able to select
the zlib options. I have no trouble selecting zlib decompession and compression
after mv .config config ; make mrproper when using 2.4.18-4. I suggest you
upgrade to kernel-2.4.18-4 first.
I've found a work-around. I think that this points to a bug in the
When I ran xconfig originally, I just loaded the appropriate canned config file
(configs/kernel-2.4.18-athlon.config) and then did a save-and-exit. Failure
followed during a subsequent make.
I managed to build successfully by adding a second xconfig step. During this
step, I visited every menu but made no changes (I hit the next button a lot).
When I did a save and exit, I found that some things in the .config changed.
And a build would succeed.
Here are the changes made by the second xconfig:
root@redsky linux-2.4]# diff .config.saved .config
< # CONFIG_JBD is not set
> # CONFIG_JBD_DEBUG is not set
> # CONFIG_HIGHMEM_EMULATION is not set
Had this with the configs/kernel-2.4.18-i686-smp.config.
load configuration from file
save and exit
Failed with zlib errors
load configuration from file
library routines - don't change anything
save and exit
This works ok.
Created attachment 57265 [details]
mailing list message with more observations and analysis
@ firstname.lastname@example.org , please refer to the discussion of this problem on
valhalla-list. This bug report is NOT about finding a work-around, but to pin
down a bug in the "make xconfig" tool. To reproduce:
[don't touch anything]
[save & exit]
At this point, the zlib settings in .config are both 'm' which is bad. "make dep
bzImage" will fail linking lib/lib.a which doesn't contain zlib_inflate.
I second the comment by email@example.com regarding a suspected bug in the
I ran into the same problem trying to build a new 2.4.18-4 kernel on a
dual-2.0GHz-P4 HP X4000.
Running xconfig and exiting without making any changes resulted eventually in a
fault during "make modules".
Stepping through all the dialogs in xconfig, making no changes, solves the
I am surprised to find that anyone does make xconfig.
If is often out of sync. The right procedure is to copy
the config from configs/ directory into .config, then
run make oldconfig. This should not produce any errors
or ask any questions, and this is what RPM does when we
build the kernel.
Sounds like a NOTABUG material to me. Convince Marcelo to
sustain xconfig better.
Arjan: you don't mind if I take this? Obviously a support question...
I've been using this kernel build procedure on RH kernels since 6.0 and it has
worked. I frequently build kernels. I'm using RH supplied configs. Not
Marcelo-supplied kernels or configs.
I don't know what is busted, but it was recently busted and ought to be fixed.
Closing with WONTFIX.
I looked into the problem and I do not see an easy fix.
It does not mean that a fix is impossible, but the configuration
language implementation in xconfig is a hefty chunk of code,
and we do not have time for it.
[BTW, while looking, I fixed some small things, they are in
Also, an easy workaround exists. Configure with xconfig,
then do "make oldconfig". Since a configuration is 99% done,
"make oldconfig" is not going to ask many questions (perhaps none),
but it will re-apply constrains correctly.
I asked upstream on linux-kernel, and got a reply.
Date: Thu, 01 Aug 2002 00:59:52 +1000
From: Greg Banks <firstname.lastname@example.org>
> BTW, what I sent was a low hanged fruit that I picked.
> The main bug is worse, and I have no idea how to fix it.
> This is what we have in configuration:
> tristate 'ISO ...' CONFIG_ISO9660_FS
> dep_bool ' Tranparent ...' CONFIG_ZISOFS $CONFIG_ISO9660_FS
> if [ "$CONFIG_ZISOFS" = "y" ]; then
> define_tristate CONFIG_ZISOFS_FS $CONFIG_ISO9660_FS
> define_tristate CONFIG_ZISOFS_FS n
> [...]it seems that tkparse
> chokes on the very innocently looking first part.
Actually, it's not innocent at all, the documentation does not allow
the construction "define_tristate CONFIG_FOO $CONFIG_BAR". The last
argument has to be a tristate literal, one of "y" "m" or "n". It might
look ok but that's because you're thinking shell not config language.
Remember, config language is *not* shell.
The relevant section from Documentation/kbuild/config-language.txt is:
> === define_tristate /symbol/ /word/
> This verb assigns the value of /word/ to /symbol/. Legal input values
> are "n", "m", and "y".
If you're trying to do what I think you're trying to do, the correct
construct is this:
dep_mbool ' Tranparent ...' CONFIG_ZISOFS $CONFIG_ISO9660_FS
if [ "$CONFIG_ZISOFS" = "y" ]; then
if [ "$CONFIG_ISO9660_FS" = "y" ]; then
define_tristate CONFIG_ZISOFS_FS y
define_tristate CONFIG_ZISOFS_FS m
define_tristate CONFIG_ZISOFS_FS n
If it's any consolation, you're not the only one to get it wrong.
arch/m68k/config.in:498: define_tristate CONFIG_SERIAL $CONFIG_DN_SERIAL
drivers/isdn/capi/Config.in:11: define_tristate CONFIG_ISDN_CAPI_CAPIFS
drivers/parport/Config.in:18: define_tristate CONFIG_PARPORT_PC_CML1
fs/Config.in:133: define_tristate CONFIG_EXPORTFS $CONFIG_NFSD
fs/Config.in:158: define_tristate CONFIG_ZISOFS_FS $CONFIG_ISO9660_FS
net/ipv4/netfilter/Config.in:58: define_tristate CONFIG_IP_NF_NAT_IRC
net/ipv4/netfilter/Config.in:67: define_tristate CONFIG_IP_NF_NAT_FTP
> The code in the menu part of kconfig.tk fixes the problem.
> In other words, the bug is only visible if someone does "make xconfig",
> loads a canned configuration which we ship, then does "save
> and exit" immediately. If he visits any menus, everything is ok.
Ah. I had reproduced your other problem differently, with this:
comment 'xconfig needs this menu'
tristate 'Set this symbol to ON' CONFIG_FOO
dep_tristate 'this is a dep_tristate' CONFIG_BAR $CONFIG_FOO m
Open the menu, set FOO=m, save, kaboom. Your patch fixes that.
<zaitcev> Yes, it seems to be a Config.in phantom, not in makefiles anywhere
<davem> Just do this:
<davem> - Kill CONFIG_ZISOFS_FS
<davem> - Make lib/Config.in checks look at CONFIG_ZISOFS+CONFIG_ISO9660_FS
<davem> - bug fixed
If this problem is not going to be fixed it should be documented.
It would seem natural to be able to do
cp /boot/config-2.4.18-24.8.0 .config
if this does not work and it's necessary to use
please change the documentation