------- 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
