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

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.

Created attachment 57265 [details]
mailing list message with more observations and analysis

@ chaos , 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.

I second the comment by hugh 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.

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

I asked upstream on linux-kernel, and got a reply.

------------------------------------------------------
Message-ID: <3D47FB68.94B9D871.au>
Date: Thu, 01 Aug 2002 00:59:52 +1000
From: Greg Banks <gnb.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.

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

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