config.sub: missing argument

doc doc256 at
Tue Mar 12 20:34:20 PST 2002

     I have found no evidece of dynamically linked files, and found that
'config.cache' and 'config.log' are both created, but config.cache has
nothing in it, and config.log, apart from the usual file description at the
very top of the file, only has one line:

configure:915:checking host system type

     And that's it. Hence the reason they are not atached to this e-mail. I
did notice another file (the only other file) in the glibc-build directory,
called 'confdefs.h' that also had nothing in it. Am I correct in assuming
that this file should have all of the command and function definitions for
configure, and if so, wouldn't it need to have alot of 'stuff' in it? Or is
it simply one of those files that are built along the way for the new
function call definitions?

Also, I've noticed at the end of the error notice, that it also prints:

/usr/src/glibc-2.2.5/glibc: --enable-add-ons : command not found

     I think that it's only reporting that because the inital configure
stage failed, and didn't know what to do with the 'switches' after the
failed configure atempt. By the way, 'glibc' is the name of the script that
I have been using to install (or trying to install) glibc with. The first
time I tried to build it, I typed it all out by hand, but decided to take
the easy way out, after several failed atempts. I've copied & pasted the
commands directly to a new text file, direct from the book, double checked
everything, saved it, then changed the permissions so that it's executable
by all, copied it to the working directory, and dragged it onto the konsole,
deleting /mnt/lfs from the command line (as i'm dragging it from a file
manager process started by root, in the host system, before chroot'ing to
the new lfs system), and then running the script.
     Now as I'm copying the commands directly from the book, and hopelessly
depending on it when I type the commands by hand, There can't be an error in
what I'm typing unless there is an error in the book (but i doubt it), I've
also re-built all of the other programs, following the book to the letter
eg: no optimizations, and installed all patches, employed all fixes when
needed as per the books instructions, and still cannot get it to work.

     I know that you are probibly working quite hard to fix this for me, so
I would like to thank you now for the assistance you and everyone on #lfs
have given me.

     The only thing I haven't tryed yet, is to build it on another system. I
have an Intel 166mmx here with 32mb and a blank 2.6gb hdd. Perhaps It's
worth the try just to see if one of the files may be corrupt? I downloaded
the single (79mb) all-in-one pack, and extracted them all (and deleted them
all!!!) several times, and if they were corrupt it would've shown, but

     Let me know what you think, and thanks again for all of your help.

doc256 at

-----Original Message-----
From: Gerard Beekmans <gerard at>
To: lfs-support at <lfs-support at>
Date: Wednesday, March 13, 2002 5:22 AM
Subject: Re: config.sub: missing argument

>I was thinking that it might be a not working 'uname' program from the
>sh-utils package, but because config.guess works it means uname works too.
>Just to be sure, $LFS/proc is mounted right? It'll have to be, config.guess
>would have failed I think.
>Is there a config.cache file and config.log file created in the glibc-build
>directory? There might not be one since it's so early in the configure
>stage, but check anyways. If you have the file(s), send them this way
>I'm betting on a nont-statically linked program which may cause the
>problems. You can check for it by running something like the following:
>for file in /mnt/lfs/bin/* /mnt/lfs/usr/bin/*
> file $file | grep dynamically
>If a dynamically linked file is detected, say /bin/ls for instance, you
>would see a line like the following:
>/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>dynamically linked (uses shared libs), stripped
>If you find anything dynamically linked, reinstall the package that it came
>from. And let us know please so we'll know for next time (and it'll be in
>the online archives for the next person with the same problem to find)
>Gerard Beekmans

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list