Summary: | Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile | ||
---|---|---|---|
Product: | gcc | Reporter: | Denis Onischenko <denis.onischenko> |
Component: | bootstrap | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | denis.onischenko, gcc-bugs, jocke, lacombar, rwild, sjames, viriketo |
Priority: | P3 | ||
Version: | 4.5.0 | ||
Target Milestone: | --- | ||
See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 | ||
Host: | x86_64-unknown-linux-gnu | Target: | powerpc64-unknown-linux-gnu |
Build: | x86_64-unknown-linux-gnu | Known to work: | |
Known to fail: | Last reconfirmed: | ||
Attachments: | patch to add TARGET_LIB_PATH only when bootstrapping |
Description
Denis Onischenko
2009-10-24 20:08:19 UTC
I run the configure script as follows: ../src/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc64-unknown-linux-gnu --prefix=$(BUILDDIR)/cross-tools --disable-werror --with-sysroot=$(SYSROOT) --enable-languages=c,c++ --disable-multilib --disable-nls @if gcc-bootstrap $(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ @endif gcc-bootstrap That is only happens when doing a native bootstrap and never when doing a cross build. Actually, wait: $(RPATH_ENVVAR)=`echo "$(HOST_LIB_PATH)$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); For BASE_TARGET_EXPORTS. I can confirm this issue while building an armeb-unknown-uclibcgnueabi (big-endian) cross toolchain on i686 (Ubuntu 9.10 32-bit) using crosstool-NG. However, I cannot replicate it on any host running x86_64 (Ubuntu 9.04 or 9.10, 64-bit). Also, when building a arm-unknown-uclibcgnueabi (little-endian) this bug is not triggered. Maybe that helps. Some of the messages in the official mailing list archive related to this issue have somehow been lost (?), http://gcc.gnu.org/ml/gcc-bugs/2009-10/msg02122.html (see the thread view). I found http://old.nabble.com/Re:-Error-when-building-cross-compiler-td25755999.html where Kai Ruottu gave some interesting insight. The bug can be worked around by adding the --disable-shared configure option to the last (final) stage in the compiler build. Created attachment 19486 [details]
patch to add TARGET_LIB_PATH only when bootstrapping
Please try this patch. Thanks.
(In reply to comment #5) > Created an attachment (id=19486) [edit] > patch to add TARGET_LIB_PATH only when bootstrapping > > Please try this patch. Thanks. > I have successfuly compiled cross compiler with this patch. gcc revision is 155559. host is x86_64-unknown-linux-gnu, target is powerpc64-unknown-linux-gnu. Yep, works for me too, using crosstool-NG to build an armeb-unknown-linux-uclibcgnueabi for i686 host. Thanks Ralf! Subject: Bug 41818 Author: rwild Date: Thu Jan 7 19:53:50 2010 New Revision: 155706 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155706 Log: Fix PR bootstrap/41818. /: PR bootstrap/41818 * Makefile.tpl (BASE_TARGET_EXPORTS): Only add TARGET_LIB_PATH to $(RPATH_ENVVAR) if bootstrapping. Fix typo in comment. * Makefile.in: Regenerate. Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl Fixed. *** Bug 43194 has been marked as a duplicate of this bug. *** I encountered that issue with gcc 4.3.4 on the following target: mips-unknown-linux-uclibc. I'm currently confirming with gcc 4.3.5. If it still happen, would it be worth pulling to the 4.3 branch ? ok, 3.4.5, same target is bad too: ./mips-unknown-linux-uclibc/libstdc++-v3/config.log: error while loading shared libraries: /targets/mips-unknown-linux-uclibc/build/build-cc/./gcc/libgcc_s.so.1: ELF file data encoding not little-endian (In reply to comment #11) > I encountered that issue with gcc 4.3.4 on the following target: > mips-unknown-linux-uclibc. I'm currently confirming with gcc 4.3.5. If it still > happen, would it be worth pulling to the 4.3 branch ? Can you please confirm that the patch from comment #8 fixes the issue for you on the 4.3 (and maybe also 4.4) branch? I'd propose the backport on gcc-patches then. Thanks. |