This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj problems on win32
- From: João Garcia <jgarcia at uk2 dot net>
- To: gnustuff at thisiscool dot com
- Cc: Taras Glek <taras dot judge at shaw dot ca>, java at gcc dot gnu dot org
- Date: Fri, 30 Jan 2004 14:41:25 +0000
- Subject: Re: gcj problems on win32
- References: <IGZYYXVS98HD2VONUS62W51VSTRIDMH.401a5c57@p733>
Hi Mohan,
>I'd appreciate it if someone could comment which approach
>is better. I haven't had time to look at this much myself.
I think that your approach could be better. It isn't logical
to have to modify valid Java code to make things work.
But it still seams a "single case" solution (am I right?).
I had the problem solved, so I didn't bother to find a more
elegant solution.
Nevertheless, I use this with several other classes (placed in
a ForceClassLoader-like clase):
private static Class c1 = gnu.java.locale.Calendar.class;
private static Class c2 = java.util.GregorianCalendar.class;
private static Class c3 = gnu.gcj.convert.Input_ASCII.class;
private static Class c4 = gnu.gcj.convert.Input_UTF8.class;
private static Class c5 = gnu.gcj.convert.Input_8859_1.class;
private static Class c6 = gnu.java.locale.LocaleInformation.class;
private static Class c7 = gnu.gcj.convert.Output_ASCII.class;
and some more...
I'll probably just add (or remove) another line or so to that
list when necessary.
It is not a big problem to keep using this solution. But it
works as an extra set of declarations that are not need by
standard Java (or as an extra, and "manually" added, set of
.o files in your case)...
It would be nice if the linker could, somehow, guess those
classes.
João