Erik-Jan wrote:
Yo Erik-Jan :-) Good to hear from you again ;-)
<SNIP>
>As you can see, in the first case it uses libgcc_s.so from the host,
>in
>the second case it uses the newly build libgcc_s.so.
Good catch... guess I really should do some more host=target builds
from ix86... Will check what I get when I get home...
>If so, should we do something about it? It is something most normal
>users won't see, because they have their libgcc_s in /usr/lib.
Not I, so I should have been affected ...
Or not, with amd64 libgcc_s.so libs go to
${PREFIX}/lib/gcc/${TARGET}/${GCC_VER}/../{lib,lib64}
with --enable-version-specific-runtime-libs
(which is an annoyance as they get clobbered if you install another
gcc alongside...)
>- configure shared gcc with --enable-version-specific-runtime-libs so
>
>libgcc_s.so gets installed in
>/cross-tools/lib/gcc/i686-pc-linux-gnu/3.4.3/ instead of in
>/cross-tools/i686-pc-linux-gnu/lib/
<SNIP>
>- sed/patch the source (gcc/gcc.c) so the hard-codes /usr/lib gets
>replaced by /tools/lib:
>sed -i "/standard_exec_prefix_/s%/usr%/tools%g" gcc/gcc.c
>
>My preference would be the sed/patch, because it removes all the
>hardcoded host-dirs from gcc's search-path.
>
My preference is both, but the sed will do for the moment
Using --enable-version-specific-runtime-libs solves another issue
with multilib builds which is currently hacked around by removing
a -B${PREFIX}/${TARGET}/lib during the build... (this gets supplied
by a -L anyway, which gets altered by the multilib spec, -B does not)
Hadn't got around to implementing that yet though during the cross or
target gcc builds, the scriptage gets interesting for multilib ;-)
Best Regards
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
