This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: cygwin issues
- To: alk at pobox dot com
- Subject: Re: cygwin issues
- From: Tom Tromey <tromey at redhat dot com>
- Date: 31 May 2001 12:25:39 -0600
- Cc: java at gcc dot gnu dot org
- References: <15117.33812.451036.87874@spanky.love.edu>
- Reply-To: tromey at redhat dot com
>>>>> "Tony" == Tony Kimball <alk@pobox.com> writes:
Tony> 1) There are duplicate definitions of java::lang::Class::Class() in
Tony> natClass.o (inlined public constructor from Class.h) and Class.o
Tony> (private constructor). I removed the inline public definition.
If that works then it is fine. Could you send a patch and ChangeLog
entry?
Tony> 2) The #pragma weak for JNI_OnLoad was ignored, so I #if 0'd out the
Tony> calls.
We'll need something better here. I like Jeff's idea of a check for
weak symbol support. If that is too hard to write a test for we could
make it platform-dependent by adding a new variable to configure.host.
Tony> - I applied a patch from the mailing list to fix vtable symbols:
Tony> http://gcc.gnu.org/ml/java/2001-04/msg00349.html
This patch didn't seem to get reviewed. Jeff, is it still needed? I
didn't see it in the gcc3 ChangeLog.
Tony> - timezone definitions conflict. The cygwin sys/time.h and time.h
Tony> are a bit messy. I just #if 0'd the case of char *timezone(),
Tony> and eliminated the '#define timezone _timezone' (to prevent
Tony> conflicts with "struct timezone", and did s/timezone/_timezone/
Tony> in java/lang/natSystem.cc and java/util/natGregorianCalendar.cc.
This won't be as much of a problem in the future, since we ditched
natGregorianCalendar.cc. If you could come up with a clean patch for
natSystem.cc, that would be great. Use the trunk for this though.
Tony> - alloca. ok, this should be obvious to me, but its not. There's
Tony> seemingly no alloca.h for cygwin, so I just changed references to
Tony> __builtin_alloca.
Could you make a separate patch to change alloca to __builtin_alloca?
I think we could just check that in.
Tony> - More JNI crud. I did a bunch of stuff like this:
Tony> +#ifdef ENABLE_JNI
Tony> _Jv_JNI_Init ();
Tony> +#endif
How extensive are the no-JNI changes? I think this is actually
something we'd like. I picture a `--disable-jni' configure flag.
Tom