On 5/31/05, Mike Dewan <[EMAIL PROTECTED]> 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 trouble. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
