Mail Archives: cygwin/2001/07/04/14:30:15
>>>>> "Julian" == Julian Hall <jules AT acris DOT co DOT uk> 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/
- Raw text -