On Thu, 21 Jul 2005, Jens Olav Nygaard wrote:
> Btw., this is where the library resides:
>
> bash-3.00# find /tools/ -name 'libgcc_s.so.1' -exec ls -l {} \;
> -rw-r--r-- 1 lfs lfs 160090 Jul 21 15:46 /tools/lib/libgcc_s.so.1
>
> J.O.
>
FWIW, libgcc_s.so was one of the reasons I've given up on multilib
until I can get a decent pure64 under my belt.
I wasn't keen to try newer versions of everything (my current target
is the same versions as LFS-6.1 and BLFS-6.1), and I kept ending up with
only a 32-bit libgcc_s.so.1 - the logs implied that the 64-bit version
had been overwritten by the 32-bit. I'm sure the cross-lfs instructions
and patches work fine, and the error is probably down to something I
overlooked, or added, but I was just banging my head against a brick
wall trying to identify the cause.
Overall, there's a bit too much magic in the toolchain for mere mortals
to comprehend ;) There is stuff in gcc that assumes x86_64 will use
lib64. I'm in the middle of doing some testing on my pure64 build, and
I couldn't 'make bootstrap' in a new gcc non-cross build until I looked
at the glibc-2..4-amd64_lib-2.patch referenced from
http://www.schneider-berlin.net/pages/basis.html
and realised I needed to do something similar to prevent some of the
binaries (e.g. genmodes) trying to use /lib64/ld-linux-x86-64.so.2.
I've now completed a gcc bootstrap (thanks, Theo) so I guess my pure64
system isn't totally broken.
As Ryan used to say - fun, fun, fun.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
