Matt Darcy wrote:
Dominic Ringuet wrote:
Simply reporting so nobody else wastes time on this. May be it could
be added to the FAQ that describes this problem.
if '/usr/lib/gcc/i686-pc-linux-gnu/specs' exists on the host system,
the binaries compiled in chapter 5, even with the specs patch properly
applied in gcc-pass2, will be linked to '/lib/ld-linux.so.2' and
chroot will fail at the beginning of chapter 6 giving:
'/tools/bin/env: no such file or directory'
Simply ensure no host specs overrides the build in chapter 5.
Dominic.
I don't believe thats the case.
I think its more reasonable to suggest that you have made a mistake
adjusting the toolchains linker.
Matt
There has been at least twenty builds with the same scripts; Any other
errors would have been caught.
The only way to chroot once the tools were built was eg:"chroot /mnt/lfs
/tools/lib/ld-linux.so.2 /tools/bin/bash" so the right dynamic linker
could be used.
There is always the exception in exceptional environment, but:
SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &&
gcc -dumpspecs > $SPECFILE &&
unset SPECFILE
then start building chapter 5; tcl, expect and dejagnu will be linked to
/tools/lib/ld-linux.so.2 wich is fine.
after the second pass of gcc 4.0.2:
readelf -l /tools/bin/gcc|grep ld-linux.so.2 -> /tools/lib/ld-linux.so.2
[OK]
after the second pass of binutils 2.16.1:
readelf -l /tools/bin/ld|grep ld-linux.so.2 -> /lib/ld-linux.so.2
[FAIL]
And all the way down to the end of the chapter, everything was linked
against /lib/ld-linux.so.2
I can't test with any other system and building takes time so I can't
tell right now if reinserting the file will reproduce the bug. But I can
tell for sure that removing /usr/lib/gcc/i686-pc-linux-gnu/specs did
fixed my '/tools/bin/env /tools/bin/bash: no such file or directory'
problem upon entering chroot in chapter 6.
I know it sounds weird that gcc read that specs file without honoring
the $PATH; without even honoring it's base install directory as if the
specs file search order was hardcoded in gcc. (as if /usr/lib being the
first logical place to look)
I am usually a very silent mailing list reader and don't want to make
noise that is not useful. I know sometimes peoples who wants to help are
more hampering than contributing, but that's not my goal, neither to get
under any spotlights. Time is short and I respect peoples that saves
mine by contributing their knowledges on the net. How many times did I
saved whole days and even weeks only because someone somewhere wrote:
"In case anybody get the same bug so they can save their time..."
By the way I wanted to say both 'congratulations' and 'thank you' for
the LFS project. It is amazing what we can learn here. Continue the good
work folks.
Dominic.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
