We've found that GCC builds fine on Solaris when using the most recent version of binutils (it may work fine with others, but that's what we used). However, in order to get 64-bit support, binutils had to also have been built on a 64-bit platform. For example, if we built binutils on Solaris 2.6, we could not build GCC with support for 64-bit binaries (similar error to what you posted below). But, if we built binutils on Solaris 8 and then built GCC using those, things worked great. Cheers, Lyle -----Original Message----- From: Mario Nigrovic; RVVK40 [mailto:Mario.Nigrovic@xxxxxxxxxxxx] Sent: Thursday, October 09, 2003 7:39 PM To: gcc-help@xxxxxxxxxxx Subject: GCC compile failure on Solaris 7 & 8 (Solution included) Folks - 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
