Ken Moffat schrieb:
> 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
no problem, i am glad that my side will help you.
Theo
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
