Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com To: Julian Hall Cc: cygwin AT cygwin DOT com, java AT gcc DOT gnu DOT org Subject: Re: Compiling libgjc under cygwin References: <3B421165 DOT 1D114955 AT acris DOT co DOT uk> X-Zippy: I HAVE a towel. X-Attribution: Tom Reply-To: tromey AT redhat DOT com From: Tom Tromey Date: 04 Jul 2001 12:44:12 -0600 In-Reply-To: Julian Hall's message of "Tue, 03 Jul 2001 19:39:33 +0100" Message-ID: <87ae2k4jr7.fsf@creche.redhat.com> Lines: 105 X-Mailer: Gnus v5.7/Emacs 20.5 >>>>> "Julian" == Julian Hall writes: Julian> Hi; I know that for the moment this is unsupported but I'm Julian> trying to get libgjc from the gcc-3.0 distribution to compile Julian> in a cygwin environment. You'd probably have an easier time starting from the gcc cvs trunk (aka "3.1"). This way (assuming paperwork is in order and you're interested in doing this), we could simply check in patches piecemeal as you write them. Julian> - I've looked at win32-threads.cc and the threads porting Julian> documentation, and guess from the looks of it that it should Julian> work OK as distributed (?) It is unclear to me. I believe the Windows thread code is largely correct, but it doesn't properly implement Thread.interrupt (neither does the Posix thread code, right now). However, I'm far from certain. (I see now that other people in this thread have responded about this. They are probably right.) Julian> - I modified configure so that it would recognise gcc's win32 Julian> thread model and choose win32-threads.cc Nice. Please send a patch for this. BTW what is your paperwork status with the FSF? Can we get you to sign things so that we can check in your patches? (We can accept a small number of small patches without paperwork, but things really are easier once this hurdle is cleared.) If you can sign paperwork, contact me off-list and I will send you the form. Julian> - The resulting makefile had java.awt packages that failed to Julian> compile, so I simply removed all of the awt and related Julian> sources. I think the compilation errors here were due to the Julian> case-insensitivity of the file system: they were effectively Julian> errors about duplicate class definitions in (eg) image.java Julian> and Image.java. We've talked about this on the list before. I believe compiler modifications will be necessary to make this work correctly. Tony Kimball (who is on this list) has done some work on the Windows port. I forget what patches he has, but he might have this one. Also David Billinghurst has done some work here. Offhand I don't know his status either :-( Julian> - java/util/natGregorianCalendar.cc wasn't compiling Julian> correctly; I had to forcibly undefine HAVE_TIMEZONE to Julian> persuade it to work, as the definition of 'timezone' it used Julian> was incompatible with the cygwin definition. On the cvs trunk, we've removed natGregorianCalendar.cc. Julian> - Fastjar required patching in order to function correctly; Julian> the patch I applied is attached, and simply causes files to be Julian> opened with the O_BINARY flag if it is defined. Nice, thanks. In the future please write a ChangeLog entry when you send a patch. I'll check this one in sometime. Julian> multiple definition of `java::lang::Class::Class()' I just saw a PR about this. I'm not positive of the cause, as I have not seen the problem myself. The PR recommends changing java/lang/Class.h so that this: Class () {}; becomes: Class (); This seems reasonable to me. Julian> /usr/local/src/gcc-cygwin-w32threads/i686-pc-cygwin/libjava/../../../gcc-3.0/libjava/win32-threads.cc:129: Julian> undefined reference to `operator new(unsigned)' Offhand I don't know why you get this. Julian> undefined reference to `JNI_OnLoad' This happens because Windows can't handle the weak definition of JNI_OnLoad. The very best approach would be to have a `HAVE_ATTRIBUTE_WEAK' test in configure.in which would fail on Windows; then we could conditionally use JNI_OnLoad. That might be hard to actually write. So the second best would be to do the same thing but instead of doing a test, just use a setting in configure.host. Julian> ./.libs/libgcj.a(SimpleTimeZone.o)(.data+0x0):SimpleTimeZone.java: Julian> undefined reference to `Jv_byteVTable' I don't understand this one. I don't really know much about Windows, and what I did know I forgot (I last did Windows work in 1997). I seem to recall that there was a difference in the linking model that made some things work strangely (from a Unix linking perspective). Some of these undefined references (Jv_*VTable at least) are to data symbols, not functions. Does that make a difference? Failing that, I tend to approach these problems by using `nm' to see if I can understand what is actually being generated versus what I expect. The Jv_*VTable symbols are all defined in prims.cc. Tom -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/