mauve test configure file?

Mark Wielaard mark@klomp.org
Sat Feb 22 18:35:00 GMT 2003


Hi,

On Sat, 2003-02-22 at 15:52, Andreas Tobler wrote:
> Mark Wielaard wrote:
> > This does look good. I have added comments for the tests were I know
> > what is wrong. (I have CCed java@gcc.gnu.org so others know of the
> > status).
> 
> And I didn't cc java@gcc.gnu.org since it was a first run and I had a 
> massive swapping happen during the tests. I ran in parallel a bootstrap 
> and so not all results seem to me reliable. So I guess some timeout are 
> coming from there.

Sorry about that. I just wanted to make sure that others on the list
know about the failing/unanalyzed Mauve failures. (And I am truely happy
that the first results already look this good, could not resist sharing
that with others.)

> >>FAIL: gnu.testlet.java.lang.String.getBytes13: String.getBytes("Cp1252") 
> >>(number 1)
> >>FAIL: gnu.testlet.java.lang.String.getBytes14: 
> >>String.getBytes("windows-1252") (number 1)
> > 
> > These two are the same encodings under different names (aliases).
> > Do you have iconv? Are they listed in iconv --list?
> 
> No, I don't have iconv installed, may I should try?

Yes, if configure detects libiconv then gnu/gcj/convert/natIconv.cc will
make those en/decoders available to libgcj. You can also use configure
--with-libiconv-prefix=DIR. If iconv isn't found it will suggest
"consider installing GNU libiconv".

> >>FAIL: gnu.testlet.java.lang.String.getBytes14: 
> >>String.getBytes("ISO-8859-15") (number 1)
> > 
> > This is a common alias for ISO8859-15 which we should probably just add
> > to out own encoding alias tables.
> 
> Yes, I remember this writing style from Xfree86. There I saw these 
> 'aliases'.

The standard is http://www.iana.org/assignments/character-sets (rfc2278)
But Sun seems to throw in some aliases of its own, see
http://java.sun.com/j2se/1.4.1/docs/guide/intl/encoding.doc.html

> > I am seeing some of these to. Haven't analysed them yet. Note that for
> > some of these you need a internet connection that can reach the
> > sources.redhat.com machine.
> 
> Well, I am in a 192.168 segment with cable access?

That should do it. As long as you can make HTTP access to that machine.

> > You don't seem to have the following failures which I am seeing:
> > FAIL: gnu.testlet.java.security.SecureRandom.Instance: uncaught exception at  number 1: java.lang.InternalError: no SHA implementation found
> > FAIL: gnu.testlet.java.security.SecureRandom.SHA1PRNG: found implementation (number 1)
> > FAIL: gnu.testlet.java.security.SecureRandom.SHA1PRNG: no implementation found (number 1)
> > FAIL: gnu.testlet.java.security.Security.property: uncaught exception at  number 1: java.lang.NullPointerException
> > 
> > Maybe those occur because I don't do a make install before running make
> > check. Have to test that.
> 
> I didn't do an install either. Just out of the build tree a make check 
> RUNTESTFLAGS...

It does seem to be dependent on wheter the classpath.security or
libgcj.security file can be loaded or not. Will look how to fix this by
falling back on the standard provider in that case.

Cheers,

Mark

Cheers,

Mark



More information about the Java mailing list