[Bug libffi/21782] configure: error: unknown endianess

["papadopo at shfj dot cea dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From papadopo at shfj dot cea dot fr  2005-05-30 12:43 -------
We're heading in the wrong direction.

I don't see how '-v' can help. The problem is just that LD_LIBRARY_PATH contains
/usr/local/lib which contains a link to the 32-bit libgcc_s.so.1 library of gcc
4. Once I reset LD_LIBRARY_PATH running 'conftest' works:

$ file conftest
conftest:	ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not
stripped
$ 
$ ldd conftest
	libgcc_s.so.1 =>	 /usr/local/lib/libgcc_s.so.1  - wrong ELF class: ELFCLASS32
	libc.so.1 =>	 /usr/lib/64/libc.so.1
	libdl.so.1 =>	 /usr/lib/64/libdl.so.1
	/usr/platform/SUNW,Sun-Blade-1000/lib/sparcv9/libc_psr.so.1
$ 
$ env ldd conftest
	libgcc_s.so.1 =>	 /export/Plocal/GCC-3.3.6/gcc/sparcv9/libgcc_s.so.1
	libc.so.1 =>	 /usr/lib/64/libc.so.1
	libdl.so.1 =>	 /usr/lib/64/libdl.so.1
	/usr/platform/SUNW,Sun-Blade-1000/lib/sparcv9/libc_psr.so.1
$ 
$ file -h /usr/local/lib/libgcc_s.so.1
/usr/local/lib/libgcc_s.so.1:   symbolic link to ../gcc-4.0.0/lib/libgcc_s.so.1
$ 


I assume the configure script resets LD_LIBRARY_PATH itself (otherwise it would
hardly be robust) so this is not an issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782