libjava status on Solaris 8/Intel and IRIX 6.5

Rainer Orth ro@TechFak.Uni-Bielefeld.DE
Mon Mar 18 12:05:00 GMT 2002


Tom Tromey writes:

> >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
> Rainer> i386-pc-solaris2.8	--disable-nls --enable-libgcj
> 
> Could you write and test a top-level patch to enable libgcj on this
> platform whenever Java is enabled?  I think it is good enough that
> --enable-libgcj should not be required any more.

This won't be necessary: ${libgcj} isn't in the toplevel configure.in's
noconfigdirs for i?86-*-solaris2*, so it will be enabled by default.

> Rainer> mips-sgi-irix6.5	CC=cc
> Rainer> 			--disable-nls --enable-libgcj
> 
> Likewise.

Seems dangerous, given that you need the kernel config trickery to get a
reasonable command line length limit.

> Rainer> # of unexpected failures	29
> 
> What are the failures here?  Do we need the divide subroutine and
> reference-checking patch here too?

They are listed in

	http://gcc.gnu.org/ml/java/2002-03/msg00392.html

Here's the overview for the spec changes:

*-*-solaris2* and mips-sgi-irix6* need REFERENCESPEC (i.e. -fcheck-references)
i?86-*-solaris2* needs the default DIVIDESPEC (i.e. -fuse-divide-subroutine)

Looking into this, I noticed a problem: right now, we have
libjava/configure.host.  Comparing this to the libstdc++-v3 situation, this
seems wrong: this should be configure.target and there should be separate
switches on target_cpu, target_os and the full target triple.  Otherwise,
handling the common Solaris 2 REFERENCESPEC becomes messy.  If there's
agreement that this is the right way to handle this, I can provide a patch.

> Rainer> The -mabi=64 tests are much worse due to one common error:
> Rainer> ld64: FATAL   9  : I/O error (-ldl): No such file or directory
> 
> Rainer> whereas mips-sgi-irix6.5/mabi=64/libjava/libgcj.spec has only
> Rainer> *lib: -lgcj -lm  -lgcjgc  -lzgcj   %(libgcc) %(liborig)
> Rainer> but make check doesn't use the different spec file.
> 
> Why is that?  Maybe there is a test suite bug we can fix.

Indeed: libjava/testsuite/lib/libjava.exp hardcodes -B$objdir in several
places to have gcj find the uninstalled libgcj.spec.  This doesn't take
multilibs into account.  I won't be able to work on a patch now, since I'll
be away soon until wednesday.

	Rainer



More information about the Java mailing list