libgcj/6158: libgcj won't boostrap on sparc-sun-solaris2.8 if already installed
Gerald Pfeifer
pfeifer@dbai.tuwien.ac.at
Wed Apr 3 08:26:00 GMT 2002
>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:
More information about the Java-prs
mailing list