Compiling libgjc under cygwin

Robert Collins
Tue Jul 3 15:33:00 GMT 2001

----- Original Message -----
From: "Julian Hall" <>
To: <>; <>
Sent: Wednesday, July 04, 2001 4:39 AM
Subject: Compiling libgjc under cygwin

> Hi; I know that for the moment this is unsupported but I'm trying to get
> libgjc from the gcc-3.0 distribution to compile in a cygwin environment.

What target do you have (win32/mingw | cygwin | unix*) ?

> I've figured out the following:
> - I've looked at and the threads porting documentation,
> and guess from the looks of it that it should work OK as distributed (?)

Ah, no. Cygwin != win32. On cygwin, to ensure that fork() and fork()
dependant calls work properly I strongly recommend the use of pthreads. Some
serious bugs and have been corrected recently so they should :} be working
fine. Speed wise they are now comparable to the win32-pthreads library.

win32 threads _may_ work, but no guarantees.

> - I modified configure so that it would recognise gcc's win32 thread
> model and choose
> - The resulting makefile had java.awt packages that failed to compile,
> so I simply removed all of the awt and related sources.  I think the
> compilation errors here were due to the case-insensitivity of the file
> system: they were effectively errors about duplicate class definitions
> in (eg) and

There were patches posted by me and another cygwinner whose name escapes me
(sorry!) about 4-5 months ago. Search for cygwin in the java list archives.
I go the filename issues fixed at that point. Unfortunately the patches
weren't really ready for integration - they would likely have destabilised
unix platforms. Some enthusatic cygwin + java person probably needs to hop
on and stay on the java list.

> - java/util/ wasn't compiling correctly; I had to
> forcibly undefine HAVE_TIMEZONE to persuade it to work, as the
> definition of 'timezone' it used was incompatible with the cygwin
> definition.

There are patches that dont' require breaking unix for this.

> - Fastjar required patching in order to function correctly; the patch I
> applied is attached, and simply causes files to be opened with the
> O_BINARY flag if it is defined.

I don't think we had tackled that (bin mounts were used) - thanks for the

> However, I am still faced with compile errors when it comes to linking
> the utilitty programs that are part of the library; the errors
> specifically are:
> ./.libs/libgcj.a(natClass.o): In function `ZN4java4lang5Class4sizeEv':
> multiple definition of `java::lang::Class::Class()'

This looks like the case sensivity thing we already squashed. Try looking up
our old patches.


More information about the Java mailing list