GCC compile failure on Solaris 7 & 8 (Solution included)

["Mario Nigrovic; RVVK40" <Mario dot Nigrovic at Motorola dot com>]

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