libgcj/6158: libgcj won't boostrap on sparc-sun-solaris2.8 if already installed

[Gerald Pfeifer]

>Number:         6158
>Category:       libgcj
>Synopsis:       libgcj won't boostrap on sparc-sun-solaris2.8 if already installed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 03 08:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.2 20020403 (experimental)
>Organization:
>Environment:
System: SunOS nunki 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-60
Architecture: sun4

	
host: sparc-sun-solaris2.8
build: sparc-sun-solaris2.8
target: sparc-sun-solaris2.8
configured with: /sw/test/gcc/cvs//configure --prefix=/sw/gcc-current --enable-languages=c,c++,java --enable-libgcj
>Description:
	libgcj causes bootstrap failures on sparc-sun-solaris2.8 if some
	version of libgcj already exists in the --prefix; this is due to
	some peculiarity of Sun ld.

	Because of this problem libgcj is disabled by default on
	sparc-sun-solaris2.8, so the problem can only be seen when
	--enable-libgcj has been specified.

	On the other hand, this is also a problem, because this way the
	library won't be built even in cases where the bootstrap failure
	wouldn't even occur.

	Rainer Orth and Alexandre Oliva have done some analysis at:
	  http://gcc.gnu.org/ml/java/2002-03/msg00348.html
	  http://gcc.gnu.org/ml/java/2002-03/msg00343.html

	Alexandre's suggestion

	  Perhaps we could test for ${libdir}/libgcj.la and error out if it's
	  present, telling the user to use a different prefix or remove the
	  earlier version, but only if using Solaris' ld.

	seems like a useful approach to me, at least an improvement from what
	we currently have.

>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: