This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: solaris2 libjava 500 failures


>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

>> 2001-04-24  Tom Tromey  <tromey@redhat.com>
>> * lib/libjava.exp (find_jvscan): Use UTF-8 encoding.
>> (libjava_init): Likewise.

Kaveh> I tried it and things got wierd.

Kaveh> First of all, the test counts went way down, e.g. from
Kaveh> yesterday:

I don't have a theory about this part.

Kaveh> Another oddity is that I'm seeing these warnings in
Kaveh> "compilation from source" checks in e.g. the ArrayClass test
Kaveh> but also others.

I'm afraid I don't understand this.  Could you rephrase it?

If you mean that the "unknown encoding" problem used to occur in
compilation from source checks, then that is where we expect it.
The encoding only matters when compiling from source.

>> ld: warning: file
>> /tmp/foo/java-trunk/build/sparc-sun-solaris2.7//libjava/.libs/libgcj.so:
>> attempted multiple inclusion of file

I don't understand this either.  I don't see this in my Solaris 2.6
build.  I'm using the GNU linker though.

I'm guessing that what is going on is that for some reason the Sun
linker (which I assume you are using) doesn't like this, and gcj is
pulling in libraries twice via libgcj.spec.  I don't think there is a
simple fix for this.  Maybe ripping out the library-finding code in
libjava.exp would do it.

Kaveh> I'm also still getting some encoding problems from jv-scan:

I must have done something wrong, because my test run also shows that
jv-scan isn't being invoked with --encoding=UTF-8.  I'll look into
this.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]