6.11 - Glibc-2.3.4 - /tools/bin/gcc: No such file or directory

Mike Dewan fp.unit at gmail.com
Mon May 30 22:57:08 PDT 2005

On 5/31/05, Mike Dewan <fp.unit at gmail.com> wrote:
> When attempting to run the configure script for Glibc-2.3.4-20040701 a fatal
> error occured, dumping this relevant section of the config.log file:
> ...
> configure:2310: checking for gcc
> configure:2326: found /tools/bin/gcc
> configure:2336: result: gcc
> configure:2580: checking for C compiler version
> configure:2583: gcc --version </dev/null >&5
> ../glibc-2.3.4-20040701/configure: line 2584: /tools/bin/gcc: No such
> file or directory
> configure:2586: $? = 127
> configure:2588: gcc -v </dev/null >&5
> ../glibc-2.3.4-20040701/configure: line 2589: /tools/bin/gcc: No such
> file or directory
> configure:2591: $? = 127
> configure:2593: gcc -V </dev/null >&5
> ../glibc-2.3.4-20040701/configure: line 2594: /tools/bin/gcc: No such
> file or directory
> configure:2596: $? = 127
> configure:2600: checking for suffix of object files
> configure:2621: gcc -c   conftest.c >&5
> ../glibc-2.3.4-20040701/configure: line 2622: /tools/bin/gcc: No such
> file or directory
> configure:2624: $? = 127
> configure: failed program was:
> ...
> When trying to actually use the compiler from the new chrooted environment
> (remember glibc is the first source actually -compiled- in Ch. 6) I get the
> "No such file or directory" error. A quick FAQ search made me try this command:
> [shell]$ readelf -l /tools/bin/gcc | grep interpreter
>     [Requested program interpreter: /lib/ld-linux.so.2]
> This is where my confusion is starting to set in, because after
> applying the Ch.5 specs file, and -manually- reviewing by hand (I
> found only one occurence of /lib/ld-linux.so.2 which needed to be
> replaced, so possibly I missed some occurences. The sed command seemed
> to execute and not replace, so I adjusted the file by hand in Vi using
> regex searches...)
> So I thought I got all occurences but I was tired, vim didn't have
> syntax highlighting for regex searches, and basically I could have
> missed some. While adjusting the Ch.5 temporary toolchain, I wrote
> that C file and ran the new compiler, then the readelf command as
> shown in the big yellow box, to a tee. What made me keep going and not
> retry anything was the fact that I infact -did- get the expected
> results of the readelf command from Ch.5:
> [shell]$ readelf -l a.out | grep interpreter
>     /tools/lib/ld-linux.so.2
> My host system is a fairly fresh Fedora Core 3 system, with minimal
> tools except development tools installed, basically for the sole
> purpose of installing LFS successfully for the first time.

Sorry, while describing the technical errors I forgot to ask my actual
questions! Here goes, I might be making some false assumptions but I
hope I am not.

A) Do I have to step back out of my chroot jail to fix this problem? I
imagine I should step back to at least Chapter 5.8 - Glibc-2.3.4
installation for the first pass, and try again (this time harder!) at
the sed script to update the platforms dynamic linker. I obviously
didn't weigh the importance of that script and now I'm in trouble.

B) Assuming the answer to question A is a 'yes, step back', is it
recommended that I totally restart from that point? Until now I have
just been sequentially stepping forward with no errors until now. I'm
a little cautious chartering out into umarked waters, but I'm
installing this on a slow system (for instance: 7 SBU's is about 2-3
hours time). I have made lots of forward progress and unless all
further tools such as Perl, grep, sed and other 'non-core' toolchain
programs are linked to the old system, it would be alot faster if I
could keep them in place.

C) Is Fedora Core 3 a decent base system? I just may be tempted with
my new knowledge to download the LFS bootable CD, and install it on my
desktop. I really wanted to complete this installation on my test
computer first though, newer hardware in my desktop could cause

More information about the lfs-support mailing list