>On Mon, 1 Feb 2010 10:42:51 -0800 (PST)
>brown wrap <gra...@yahoo.com> wrote:
>
>
> When I run configure it says critical programs are too old or
> missing. I am logged into that window as user lfs. I looked at the
> environament and compared it to root's env and the paths looks the
> same. But if I run configure as root, I get no complaints. Here is
> the error, it looks to me likes its complaining about as and/or ld,
> but the paths to each is the same for both users:
>
> /mnt/lfs/sources/6.4/glibc-build$ ../glibc-2.10.1/configure
> --prefix=/tools --host=$LFS_TGT
> --build=$(../glibc-2.10.1/scripts/config.guess) --disable-profile
> --enable-add-ons --enable-kernel=2.6.18
> --with-headers=/tools/include libc_cv_forced_unwind=yes
> libc_cv_c_cleanup=yesq../glibcq LDFLAGS=-L/usr/local/lib
>
> checking whether autoconf works... yes
> configure: error:
> *** These critical programs are missing or too old: as ld
> *** Check the INSTALL file for required versions.
> lfs:/mnt/lfs/sources/6.4/glibc-build$
Can you maybe show the output of that
`../glibc-2.10.1/scripts/config.guess' up there?
Also, I see you have both $LD_LIBRARY_PATH and $LDFLAGS set up to point
to your /usr/local/lib (if this is your production system, it may be
quite a good idea to drop the $LD_LIBRARY_PATH entirely and add
/usr/local/lib to your /etc/ld.so.conf). Naturally, this can not only
wreck havoc with the build process, it also defeats the "isolate the
build from the host" principle of LFS.
As for the version mismatch, I had a similar problem when trying to use
binutils-2.20 with glibc-2.9 on a pure-64 (which I just ignored and
used binutils-2.19). I have no idea as to wether this also happens on
32-bit builds.
You should also try to find out exactly which executables of the build
packages are you using. You can give it a try by either enchanting
`which gcc' `which cpp' `which cc' `which as' `which ld', or by saying
`gcc --verbose' and inspecting the bits it spits out.
If those bits are the same as the options you gave gcc when you were
compiling it (look for "--prefix=/tools"), then you are using the newly
built GCC. If not, somehow you are picking up the host GCC from the
build enviroment (I blame $LD_LIBRARY_PATH and $LDFLAGS).
Ultimately, if you have a problem with the toolchain, that is where you
must look. For example: write a dummy C program (main(){return 42;})
and try compiling it. If it fails, it will tell you more info and
direct you to the failing component. You can also use compler flags to
see which step fails: -E to only run the preprocessor, -S to only
compile C to assembly (these two rely only on GCC), and -c to assemble
and none to do the whole process. The -c and NONE options rely on a
funcional binutils package.
So that should hopefully enable you to pinpoint the failing component.
Then we can see what is wrong whith it.
But first unset the $LD_LIBRARY_PATH an $LDFLAGS enviroment variables
and then give it a try (but start from the begining - wipe the build
filesystem clean and then begin with Chapter 5).
Hope this helps. :)
-AKuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
