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