Solaris 2.8 build

Fri Mar 15 15:43:00 GMT 2002

Tom Tromey writes:
> I see this in the top-level configure.in:
>> sparc-*-solaris*)
> case "${host}" in
> sparc-*-solaris2.8)
> # According to Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>, libjava
> # won't build correctly on Solaris 8 if there's a
> # previously-installed version of GCC in the configured prefix.
> # This problem does not show up on earlier versions of Solaris.
> noconfigdirs="$noconfigdirs ${libgcj}"
> ;;
> esac
>> Is there something we can do about it?
> Disabling libgcj in this case is unfortunate.

indeed: I've done a bit research and found what's going on:
Gerald's original report at
	http://gcc.gnu.org/ml/java/2001-04/msg00129.html
shows the problem. For an explanation, see the Solaris 8 Linker and
Libraries Guide: 
	http://docs.sun.com:80/ab2/coll.45.13/LLM/@Ab2PageView/6558
sub Recorded Name Conflicts:
The command line can be reduced to
	gcj -o jv-convert <jv-convert objs> .libs/libgcj.so
with much stuff around. gcj implicitly adds -lgcj. If a libgcj.so with
the same SONAME as the one in .libs is present in $libdir specified when
configuring gcc, gcj will effectively call ld with
	ld -o jv-convert ... .libs/libgcj.so -L$libdir -lgcj
So ld is asked to record dependencies for two different shared objects with
the same SONAME in jv-convert, which is just cannot do since all it records
is the SONAME, so it bails out.
This doubly linking the same library also caused the testsuite failures
described in 
	http://gcc.gnu.org/ml/java/2001-06/msg00247.html
and the thread starting at
	http://gcc.gnu.org/ml/java-patches/2001-q3/msg00076.html
which have now been fixed by avoiding this double linking. Maybe this can
be done here, too, or we add some -nostdlibgcj switch as proposed there.
	Rainer