solaris2 libjava 500 failures
Kaveh R. Ghazi
Thu Apr 26 08:12:00 GMT 2001
> From: Tom Tromey <email@example.com>
> >>>>> "Kaveh" == Kaveh R Ghazi <firstname.lastname@example.org> writes:
> >> 2001-04-24 Tom Tromey <email@example.com>
> >> * lib/libjava.exp (find_jvscan): Use UTF-8 encoding.
> >> (libjava_init): Likewise.
> 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.
Right, your first patch passed the encoding flag in these situations.
So while it used to error at compilation time with an encoding
problem, with your first patch it got further along to linking, where
I saw the ld warnings.
> >> 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.
Yes I'm using native as/ld. Would you please try a build configured
that way to see if you can reproduce it?
Kaveh R. Ghazi Engagement Manager / Project Services
firstname.lastname@example.org Qwest Internet Solutions
More information about the Java