Ian Lance Taylor wrote:
Denis Onischenko <denis.onischenko@xxxxxxxxx> writes:
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 --disable-checking
--with-sysroot=$(SYSROOT) --enable-languages=c,c++ --disable-multilib
--disable-nls
The -B option tells gcc where to find passes, but it does not normally
tell the dynamic linker where to find shared libraries. Something is
causing the dynamic linker to think that it should use
/a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1 rather than
/lib/libgcc_s.so.1. Is it possible that you have LD_LIBRARY_PATH set
in the environment?
No, I checked, LD_LIBRARY_PATH is not set in the environment.
I've successfuly compiled cross-gcc by adding the -disable-shared
option, but I would not want to abandon the shared gcc libraries
There is something peculiar going on, because a
x86_64-unknown-linux-gnu hosted compiler would not normally refer to
libgcc_s.so.1 at all. Even if it did, nothing would normally direct
the dynamic linker to look in the gcc build directory. Something is
wrong but I don't know what it is.
I met this same bug/feature a week or so before Denis, and decided to
investigate it now. Just the same kind of error happened here :
/data1/home/src/gcc-4.4.1/build/./gcc/xgcc -B/data1/home/src/gcc-4.4.1/build/./gcc/
-B/usr/local/sparc-solaris2.10/bin/ -B/usr/local/sparc-solaris2.10/lib/ -isystem
/usr/local/sparc-solaris2.10/include -isystem /usr/local/sparc-solaris2.10/sys-include -g -Os -c -o
/data1/home/src/gcc-4.4.1/build/sparc-solaris2.10/libgcc/crt1.o -x assembler-with-cpp
../../gcc/config/sparc/sol2-c1.asm
/data1/home/src/gcc-4.4.1/build/./gcc/xgcc: error while loading shared libraries:
/data1/home/src/gcc-4.4.1/build/./gcc/libgcc_s.so.1: ELF file data encoding not little-endian
The '-B' was the expected reason but when trying to prove this, there
was no evidence. Putting '-B' options like here in './xgcc -v' etc.
didn't get the problem appear... In any case all the produced executables
showed something like :
[root@Dell gcc]# ldd xgcc
linux-gate.so.1 => (0x00110000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00888000)
libc.so.6 => /lib/libc.so.6 (0x00996000)
/lib/ld-linux.so.2 (0x00977000)
so requiring 'libgcc_s.so.1' from somewhere at runtime... The host GCC
was gcc-3.4.x which maybe first started to link against 'libgcc_s' as
default...
The simple workaround was to use '-static-libgcc' in CFLAGS...
But maybe LD_LIBRARY_PATH is set new in the environment, the main
'Makefile' says :
# This is the name of the environment variable used for the path to
# the libraries.
RPATH_ENVVAR = LD_LIBRARY_PATH
and later :
$(RPATH_ENVVAR)=`echo "$(HOST_LIB_PATH)$$$(RPATH_ENVVAR)" | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR);
My 'sed' skills are badly rotten, so I cannot say whether this adds the
current work directory onto LD_LIBRARY_PATH :(
