Bug 80461 - "make xconfig" selects wrong default config file
Summary: "make xconfig" selects wrong default config file
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-26 20:38 UTC by Robert P. J. Day
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-30 15:40:19 UTC

Attachments (Terms of Use)

Description Robert P. J. Day 2002-12-26 20:38:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
  In the kernel source tree directory, the file
.../scripts/Makefile has (at least) two errors.

1) inconsistency in usage of "KERNTYPE" versus "KERNELTYPE"

2) the condition
   if [ -f configs/*-$KERNTYPE.config ]; then

   will not find the matching config file in the configs/
   directory.  i'm not sure what is going on here, but there's
   something about the if construct in bash that is just
   not processing that variable expansion correctly.

   if you run "make xconfig", you'll see in the final output
   a test against "ERNTYPE", as if the $K is being parsed
   as ${K}ERNTYPE.  if you edit that file with the default vim
   color settings, you'll see what i mean -- the K is blue,
   while the rest of the variable name is black.  (what's up
   with that?)

   in any event, if you don't have an initial .config file,
   that conditional will not find a perfectly appropriate
   config file in configs/, but will always use the file
   .../arch/i386/defconfig instead.

   not a fatal error, just misleading.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. look at scripts/Makefile
2. run "make xconfig" with no initial .config file, and see
the output when you exit

Actual Results:  incorrect initial config file is selected for .config

Expected Results:  the file under the configs/ directory should be selected

Additional info:

Comment 1 Miloslav Trmac 2002-12-26 23:12:39 UTC
The $KERNTYPE is expanded by make, which has a different syntax for
references of variables with multicharacter names ($(KERNTYPE) or ${KERNTYPE}).
In this case though, KERNTYPE is a shell variable, so it should be $$KERNTYPE.

Found both in vanilla RHL 8.0 and Phoebe (kernel-2.4.20-2.2)

Comment 2 Paul Campbell 2003-01-09 01:29:36 UTC
I get this error even though I have a .config file in 
/usr/src/linux-2.4 and in /usr/src/linux-2.4/configs

Comment 3 Paul Campbell 2003-01-11 21:59:04 UTC
Eureka - I solved it!

make xconfig has a dependency on wish 
which requires tk to be installed
which requires tcl to be installed.

Do you want to add a dependency to kernel-sources,
that tk and tcl must be installed?

I don't know RH procedure, even though this is a low,
it should be an easy fix. 
I bet this is also in the new beta!

Here is the error:
wish -f scripts/kconfig.tk
make: wish: Command not found
make: *** [xconfig] Error 127

I installed tcl/tk and it started up.

Both 7.3 and 8.0 have that funny ERNEL stuff but 
it doesn't matter that is NOT the problem.

Comment 4 Robert P. J. Day 2003-01-12 01:58:37 UTC
  while the dependency issue is most likely a good fix, you can't
ignore that that script still has an obvious error with the 
KERNTYPE/KERNELTYPE inconsistency at the very least.

Comment 5 Paul Campbell 2003-01-16 21:56:03 UTC
Please delete my erroneous comments #2 and #3 above.
My comments were a dup of 68323

Comment 6 Bugzilla owner 2004-09-30 15:40:19 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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