cygwin issues

[Tony Kimball <alk at pobox dot com>]

I'm working on a cygwin cross-compiler (linux host), from the 3.0
branch.  I'm having a little trouble with boehm-gc right now.  Any
tips as to what problems are likely there are appreciated.  Right now,
I am working through a stack overflow in GC_clear_stack_inner. Here
are the problems encountered and *hacked* around so far (that I
recall), submitted simply to document them:

- Weak symbols don't seem to be supported for cygwin.  I may be
  overlooking some configuration variable which would enable them.
  This was a problem in two areas:

  1) There are duplicate definitions of java::lang::Class::Class() in 
  natClass.o (inlined public constructor from Class.h) and Class.o
  (private constructor).  I removed the inline public definition.

  2) The #pragma weak for JNI_OnLoad was ignored, so I #if 0'd out the
  calls. 

- I applied a patch from the mailing list to fix vtable symbols:
  http://gcc.gnu.org/ml/java/2001-04/msg00349.html
  
- Link arguments are wrong, out of the box:
  libgcjdata.a and -lpthread are supplied to collect2.  I just work 
  around this so far.

- timezone definitions conflict.  The cygwin sys/time.h and time.h 
  are a bit messy.  I just #if 0'd the case of char *timezone(),
  and eliminated the '#define timezone _timezone' (to prevent
  conflicts with "struct timezone", and did s/timezone/_timezone/
  in java/lang/natSystem.cc and java/util/natGregorianCalendar.cc.

- alloca.  ok, this should be obvious to me, but its not.  There's
  seemingly no alloca.h for cygwin, so I just changed references to 
  __builtin_alloca. 

- More JNI crud.  I did a bunch of stuff like this:
  RCS file: /cvs/gcc/gcc/libjava/prims.cc,v
  retrieving revision 1.46.4.3
  diff -u -r1.46.4.3 prims.cc
  --- prims.cc	2001/05/20 16:24:40	1.46.4.3
  +++ prims.cc	2001/05/24 21:16:46
  @@ -683,7 +683,9 @@
     sigaction (SIGPIPE, &act, NULL);
   #endif /* USE_WIN32_SIGNALLING */
   
  +#ifdef ENABLE_JNI
     _Jv_JNI_Init ();
  +#endif
   }
   
   #ifndef DISABLE_GETENV_PROPERTIES

   Obviously jni.cc required some attention to dyke out JNI in the
   #undef ENABLE_JNI case.