I'm having a problem compiling gcc 3.3.1 on my Solaris 7 and 8 boxes. (It compiles just dandily on my Linux box.) The problem has the following symptoms, which I have seen in other posts, but never with an accompanying solution:
PROBLEM
checking whether the C compiler (/tmp/gcc.1/gcc/xgcc -B/tmp/gcc.1/gcc/ -B/tmp/GN U_temp/sparc-sun-solaris2.8/bin/ -B/tmp/GNU_temp/sparc-sun-solaris2.8/lib/ -isys tem /tmp/GNU_temp/sparc-sun-solaris2.8/include -m64 -O2 -g -O2 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. make: *** [configure-target-libiberty] Error 1
Eventually, I found the corresponding config.log:
configure:2408: /tmp/gcc.1/gcc/xgcc -B/tmp/gcc.1/gcc/ -B/tmp/GNU_temp/sparc-sun- solaris2.8/bin/ -B/tmp/GNU_temp/sparc-sun-solaris2.8/lib/ -isystem /tmp/GNU_temp /sparc-sun-solaris2.8/include -m64 -o conftest -O2 -g -O2 conftest.c 1>&5 /usr/lib/libdl.so.1: could not read symbols: Invalid operation collect2: ld returned 1 exit status configure: failed program was:
#line 2403 "configure" #include "confdefs.h"
main(){return(0);}
I've seen one response was to use --disable-multilib, but I think that it leaves you without -m64 support, which I personally need for another package I'm going to work on next.
SOLUTION
I fooled around with this, pulled lots of hair out, banged on my desk a few times, then looked a little closer at the problem. What's happening is that on link, ld is looking for libdl.so.1. It's finding a 32-bit version rather than the 64-bit version it needs. The 64-bit version is, in fact, in /usr/lib/64, which on my system is a link to /usr/lib/sparcv9.
My problem was that I very carefully control the compilation environment, and I was putting /usr/lib into LD_LIBRARY_PATH. Since ld checks there first, it's not finding the correct library. So the solution is simply to leave /usr/lib OUT of LD_LIBRARY_PATH. I surmise that the loader tacks on /usr/lib[/sparcv9] as appropriate for the binary format, but should the library be found in a previous path component, that's the one that gets loaded.
Is this an ld bug? Shouldn't it know to try the sparcv9 version of libraries first if the binary is 64-bit? It turns out I was using an older version of ld, too: GNU ld 2.10. Oops... Someday I'll check if this was fixed with more recent ld.
Mario -- Whoever fights monsters should see to it that in the process he does not become a monster. -- Nietzsche
