Hi Art,
>> Could be, see above. Apart from that, I wonder why you insist on using
>> GNU ld on Solaris. install.texi strongly suggests to use the Solaris
>> linker instead, and I stand by that advise.
>
>> A couple of comments on those configure options: avoid everything not
>> strictly necessary and stay with the defaults.
>
> { ... snip ... }
>
> I had a small script which runs 'configure' and using GNU as/ld had worked.
> I've
> adjusted the script so that GCC is configured to use Sun /usr/ccs/bin/ld
> instead
> of the GNU ld binary, and I also got rid of '--enable-threads' and the
> '--enable-libstdcxx-pch=no' options
>
> With the adjustments to the configuration my build got past the
> libgcc_s.so' error
> I'd been seeing, and proceeded into the 'stage2' build before it failed:
>
> libtool: link: /export/home/arth/src/gcc-0801/./prev-gcc/xgcc
> -B/export/home/ar
> th/src/gcc-0801/./prev-gcc/
> -B/export/home/arth/local/sparc-sun-solaris2.10/bin/
> -B/export/home/arth/local/sparc-sun-solaris2.10/bin/
> -B/export/home/arth/local/
> sparc-sun-solaris2.10/lib/ -isystem
> /export/home/arth/local/sparc-sun-solaris2.1
> 0/include -isystem /export/home/arth/local/sparc-sun-solaris2.10/sys-include
> -shared .libs/lto-plugin.o -static-libgcc -static-libstdc++
> -static-libgcc .
> ./libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o
> .libs/liblto
> _plugin.so.0.0.0
> ld: warning: option -o appears more than once, first setting taken
> ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
> ld: fatal: File processing errors. No output written to
> .libs/liblto_plugin.so.0
> .0.0
> collect2: error: ld returned 1 exit status
> gmake[4]: *** [liblto_plugin.la] Error 1
> gmake[4]: Leaving directory `/export/home/arth/src/gcc-0801/lto-plugin'
>
> I copied the failing link into a script, added a '-v' option to see what
> was going
> on, and the link command was this:
>
> /export/home/arth/src/gcc-0801/./prev-gcc/collect2 -V -G -dy -z text -M
> /export/home/arth/src/gcc-0801/./prev-gcc/libgcc-unwind.map -Y
> P,/lib:/usr/lib -Qy -o .libs/liblto_plugin.so.0.0.0 /usr/lib/crti.o
> /usr/lib/values-Xa.o /export/home/arth/src/gcc-0801/./prev-gcc/crtbegin.o
> -L/export/home/arth/src/gcc-0801/./prev-gcc
> -L/export/home/arth/local/sparc-sun-solaris2.10/bin
> -L/export/home/arth/local/sparc-sun-solaris2.10/bin
> -L/export/home/arth/local/sparc-sun-solaris2.10/lib .libs/lto-plugin.o
> ../libiberty/pic/libiberty.a -soname liblto_plugin.so.0 -lgcc -lgcc_eh -lc
> -lgcc -lgcc_eh -lc /export/home/arth/src/gcc-0801/./prev-gcc/crtend.o
> /usr/lib/crtn.o
> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
> ld: warning: option -o appears more than once, first setting taken
> ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
> ld: fatal: File processing errors. No output written to
> .libs/liblto_plugin.so.0.0.0
> collect2: error: ld returned 1 exit status
>
> The warning about the '-o' option appearing twice was really strange until
> I found out through some trial and error that the '-soname' option was the
> cause. If I run that command above but use the '-h' option instead the
> shared object links successfully:
>
> $ /export/home/arth/src/gcc-0801/./prev-gcc/collect2 -V -G -dy -z text -M
> /export/home/arth/src/gcc-0801/./prev-gcc/libgcc-unwind.map -Y
> P,/lib:/usr/lib -Qy -o ./.libs/liblto_plugin.so.0.0.0 /usr/lib/crti.o
> /usr/lib/values-Xa.o /export/home/arth/src/gcc-0801/./prev-gcc/crtbegin.o
> -L/export/home/arth/src/gcc-0801/prev-gcc
> -L/export/home/arth/local/sparc-sun-solaris-2.10/bin
> -L/export/home/arth/local/sparc-sun-solaris-2.10/bin
> -L/export/home/arth/local/sparc-sun-solaris-2.10/lib ./.libs/lto-plugin.o
> ../libiberty/pic/libiberty.a -h liblto_plugin.so.0 -lgcc -lgcc_eh -lc -lgcc
> -lgcc_eh -lc /export/home/arth/src/gcc-0801/prev-gcc/crtend.o
> /usr/lib/crtn.o
> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
> $
>
> I guess now the trick is figuring out how to have the collect2 program use
> -h' instead of '-soname' when it invokes the Sun linker. Suggestions?
it seems something is very wrong here. The use of -M
.../libgcc-unwind.map indicates that gcc configure thinks that the
Solaris ld (/usr/ccs/bin/ld) is in ise, while libtool is invoking the
linker with -soname, which only happens for GNU ld.
How exactly did you configure gcc to use the system linker? If all else
fails, I suggest to use --without-gnu-ld --with-ld=/usr/ccs/bin/ld to
make certain the right one is in use. One possible cause of your
problems could be if you have GNU ld in your path called ld. I've never
done that (I always call it gld-<version>), but the above configure
options should help if you are unable to get rid of such an ld.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
