Bug 64814 - conventional kernel build fails
conventional kernel build fails
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-13 00:50 EDT by D. Hugh Redelmeier
Modified: 2007-04-18 12:42 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-03 15:41:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
problem report, as submitted to Valhalla mailing list (4.77 KB, text/plain)
2002-05-13 00:53 EDT, D. Hugh Redelmeier
no flags Details
mailing list message with more observations and analysis (3.27 KB, patch)
2002-05-14 10:53 EDT, D. Hugh Redelmeier
no flags Details | Diff

  None (edit)
Description D. Hugh Redelmeier 2002-05-13 00:50:05 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):


How reproducible:
Always

Steps to Reproduce:
1.method is described in attached report
2.
3.
	

Actual Results:  linker errors leading to a make failure

Expected Results:  new kernel has been built

Additional info:

I've been using this technique to build RHL kernels for more than 3 years. 
(Unless I've made some silly mistake.)
Comment 1 D. Hugh Redelmeier 2002-05-13 00:53:40 EDT
Created attachment 57044 [details]
problem report, as submitted to Valhalla mailing list
Comment 2 Nathan G. Grennan 2002-05-13 03:25:49 EDT
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.
Comment 3 D. Hugh Redelmeier 2002-05-13 23:22:39 EDT
I've found a work-around.  I think that this points to a bug in the
configuration process.

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
    1444c1444,1445
    < # CONFIG_JBD is not set
    ---
    > CONFIG_JBD=m
    > # CONFIG_JBD_DEBUG is not set
    1452c1453
    < CONFIG_RAMFS=m
    ---
    > CONFIG_RAMFS=y
    1858a1860
    > # CONFIG_HIGHMEM_EMULATION is not set
    1864c1866
    < CONFIG_ZLIB_INFLATE=m
    ---
    > CONFIG_ZLIB_INFLATE=y
Comment 4 alambie 2002-05-14 05:56:45 EDT
Had this with the configs/kernel-2.4.18-i686-smp.config.

make xconfig
load configuration from file
save and exit
make dep
make bzImage

Failed with zlib errors

make xconfig
load configuration from file
library routines - don't change anything
main menu
save and exit
make dep
make bzImage

This works ok.

Comment 5 D. Hugh Redelmeier 2002-05-14 10:53:27 EDT
Created attachment 57265 [details]
mailing list message with more observations and analysis
Comment 6 Michael Schwendt 2002-05-14 11:03:55 EDT
@ chaos@okcforum.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:

  cd /usr/src/linux-2.4
  make mrproper
  make xconfig
  [load configs/kernel-2.4.18-athlon.config]
  [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.
Comment 7 ken_laird 2002-05-28 17:24:25 EDT
I second the comment by hugh@mimosa.com regarding a suspected bug in the
configuration process.
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
Segmentation 
fault during "make modules".
Stepping through all the dialogs in xconfig, making no changes, solves the
problem.
Comment 8 Pete Zaitcev 2002-06-03 15:15:41 EDT
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...
Comment 9 D. Hugh Redelmeier 2002-06-03 15:41:33 EDT
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.
Comment 10 Pete Zaitcev 2002-07-29 20:47:08 EDT
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
2.4.19-rc3-acX now].
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.
Comment 11 Pete Zaitcev 2002-07-31 12:36:56 EDT
I asked upstream on linux-kernel, and got a reply.

------------------------------------------------------
Message-ID: <3D47FB68.94B9D871@alphalink.com.au>
Date: Thu, 01 Aug 2002 00:59:52 +1000
From: Greg Banks <gnb@alphalink.com.au>

> 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
> else
>    define_tristate CONFIG_ZISOFS_FS n
> fi
> 
> [...]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
    else
	define_tristate CONFIG_ZISOFS_FS m
    fi
else
   define_tristate CONFIG_ZISOFS_FS n
fi

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
$CONFIG_ISDN_CAPI_CAPI20
drivers/parport/Config.in:18:         define_tristate CONFIG_PARPORT_PC_CML1
$CONFIG_PARPORT_PC
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
$CONFIG_IP_NF_NAT
net/ipv4/netfilter/Config.in:67:          define_tristate CONFIG_IP_NF_NAT_FTP
$CONFIG_IP_NF_NAT

> 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:

mainmenu_option next_comment
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

endmenu

Open the menu, set FOO=m, save, kaboom.  Your patch fixes that.
Comment 12 Pete Zaitcev 2002-08-26 18:29:16 EDT
Community action.

<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 
           directly
<davem> - bug fixed
Comment 13 Jim McElwaine 2003-02-07 10:01:08 EST
If this problem is not going to be fixed it should be documented.

It would seem natural to be able to do 
cd /usr/src/linux-2.4
make mrproper
cp /boot/config-2.4.18-24.8.0 .config
make dep
make bzImage

if this does not work and it's necessary to use 
make oldconfig 
after 
make xconfig
please change the documentation


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