Using crossdev -S i[56]86, gcc stage2 builds fails on SPARC, stops just after building fortran libraries. Logs attached.
Created attachment 264547 [details] cross-i686-pc-linux-gnu-info.log
Created attachment 264549 [details] cross-i686-pc-linux-gnu-gcc-stage2.log gzipped
This also happens with i586.
that detail is most likely irrelevant and can be ignored as noise
Did we ever find a resolution for this problem? Oddly enough this works OK on unstable sparc. There must be a difference between stable and unstable that makes this work. I only use crossdev -S i[56]86 to buld the cross compilers on SPARC. Also, I cannot build sparc cross compilers on x86 either.
Have a look at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553047
i'm not sure that bug report is relevant ... my quick scan of it shows that the LD_LIBRARY_PATH usage there is pretty much all coming from the Debian build scripts and not from the gcc build system.
I wonder what are the differences between unstable sparc and stable sparc, as my i[56]86 cross compilers on unstable sparc are apparently OK, same versions of crossdev used on both, both builds stable i[56]86 cross compiler tool chains.
http://bugs.gentoo.org/show_bug.cgi?id=287667#c14 too.
hmm, maybe it's the old bug i fixed in binutils 08_all_binutils-RPATH_ENVVAR-smack.patch http://sourceware.org/bugzilla/show_bug.cgi?id=4970
http://sourceware.org/ml/binutils/2007-10/msg00019.html Maybe it just needs adapting for the libgcc.so so it doesn't pick up the wrong one when linking.
*** Bug 368103 has been marked as a duplicate of this bug. ***
Same problem with cross-powerpc-unknown-linux-gnu/gcc-4.4.5 on i686 host
*** Bug 391247 has been marked as a duplicate of this bug. ***
*** Bug 434738 has been marked as a duplicate of this bug. ***
is there any way i can help to get this fixed? i need to have gcc 4.1.2 alongside 4.5.x on amd64 to develop against proprietary APIs (e.g. Autodesk Maya API). any hints where to start digging?
(In reply to Simon Haegler from comment #16) > is there any way i can help to get this fixed? i need to have gcc 4.1.2 > alongside 4.5.x on amd64 to develop against proprietary APIs (e.g. Autodesk > Maya API). any hints where to start digging? gcc-config x86_64-pc-linux-gnu-4.1.2 CFLAGS="-O2" emerge -1 gettext emerge -1 gcc:4.1 gcc-config x86_64-pc-linux-gnu-4.8.2 emerge -1 gettext
*** Bug 543824 has been marked as a duplicate of this bug. ***
I wonder if this isn't addressed by 20_all_msgfmt-libstdc++-link.patch in gcc 4.7.4, 4.8.4 and 4.9.2? That issue originates from bug #295480 which is not due to a cross compiling environment, but multiple native versions of gcc. But the same issues of a bad library path search order causing linking against the wrong libgcc_s.so.1 seems to be at the heart of it.
(In reply to Anthony Basile from comment #19) it isn't. that patch hacked one specific manifestation of the problem rather than fixing it at the underlying point.
(In reply to SpanKY from comment #20) > (In reply to Anthony Basile from comment #19) > > it isn't. that patch hacked one specific manifestation of the problem > rather than fixing it at the underlying point. Yeah I know this can manifest itself in different ways, but suspect this was precisely the same problem again from the title "host tools (msgfmt)".
(In reply to SpanKY from comment #20) > (In reply to Anthony Basile from comment #19) > > it isn't. that patch hacked one specific manifestation of the problem > rather than fixing it at the underlying point. I tried a patch Anthony gave me which solved the problem. Even thought it probably in acts on the symptoms instead of the real problem, it enhances the usability. So it is a good idea to add it, and then focus on the underlying problem.
Fun fact: /usr/bin/msgfmt on sparc32 does not link against libgcc_s.so anymore. It does on powerpc (implicitly via gettext->libxml2->libicu) but running crossdev on powerpc32 host Just Works for me for modern toolchain versions (gcc-9.2.0). Let's close it as obsolete. Feel free to open a new bug and we'll try to sort it out.