trouble installing gcc 3.0 on solaris 2.6

[Andrew Koenig <ark at research dot att dot com>]

So far, I have been unable to get gcc 3.0 to work properly under
Solaris 2.6 (sparc-sun-solaris2.6).

My installation procedure is to unpack the source into a directory
with a name that I put in a shell variable TMP, and then do this:

	mkdir $TMP/build-gcc
 	cd $TMP/build-gcc
 	CONFIG_SHELL=/bin/ksh $TMP/gcc-3.0/configure --prefix=/usr/gnu \
		--with-gnu-ld --with-gnu-as
 	CONFIG_SHELL=/bin/ksh make bootstrap
 	CONFIG_SHELL=/bin/ksh make install

I am using Gnu make and binutils 2.11.2, to forestall the problem
noted in the installation notes (``All releases of GNU binutils prior
to 2.11.1 have known bugs on this platform. We recommend the use of
GNU binutils 2.11.1 or the vendor tools (Sun as, Sun ld).'')

The problem is that when I compile even a trivial program, I get an
executable that won't execute bcause it can't find the dynamic libraries:

For example, if foo.c contains

    int main()
    {
            return 0;
    }

then the following happens:

    $ g++ foo.c
    $ a.out
    ld.so.1: a.out: fatal: libstdc++.so.3: open failed: No such file or directory
    Killed

If I give an explicit path to the shared libraries, it fails differently:

    $LD_LIBRARY_PATH=/usr/gnu/lib a.out
    Segmentation Fault - core dumped

Looking at the core dump reveals the following:

    $ gdb a.out core
    GNU gdb 5.0
    Copyright 2000 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "sparc-sun-solaris2.6"...
    (no debugging symbols found)...
    Core was generated by `a.out'.
    Program terminated with signal 11, Segmentation Fault.
    Reading symbols from /usr/gnu/lib/libstdc++.so.3...done.
    Loaded symbols for /usr/gnu/lib/libstdc++.so.3
    Reading symbols from /usr/lib/libm.so.1...done.
    Loaded symbols for /usr/lib/libm.so.1
    Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done.
    Loaded symbols for /usr/gnu/lib/libgcc_s.so.1
    Reading symbols from /usr/lib/libc.so.1...done.
    Loaded symbols for /usr/lib/libc.so.1
    Reading symbols from /usr/lib/libdl.so.1...done.
    Loaded symbols for /usr/lib/libdl.so.1
    Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
    Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
    #0  0xef757b84 in __do_global_dtors_aux () from /usr/gnu/lib/libstdc++.so.3
    (gdb) bt
    #0  0xef757b84 in __do_global_dtors_aux () from /usr/gnu/lib/libstdc++.so.3
    #1  0xef784640 in _fini () from /usr/gnu/lib/libstdc++.so.3
    #2  0xef7d96c0 in ?? ()
    #3  0xef618d30 in _exithandle () from /usr/lib/libc.so.1
    #4  0xef6874b8 in exit () from /usr/lib/libc.so.1

If, on the other hand, I compile with "g++ --static", then it links and
executes just fine.

So I expect that I am running into a dynamic linking bug that is akin
to the ones you reported for Solaris 2.7 and 2.8.  However, since the
problem appears to have been caused by a Sun patch for 2.7 that
presumably doesn't apply to 2.6, and because you don't list any
particular problems for 2.6, I am somewhat at a loss as to what to do.

Suggestions?




						Regards,


						Andrew Koenig