This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Patch to enable libgcj.dll for MinGW


This is a followup to the thread:
http://gcc.gnu.org/ml/java/2005-08/msg00136.html

The attached patch (mingw-shared-fix.diff) updates Makefile.am,
configure.ac and libltdl/libltdl.h so that a full libgcj.dll can be
built for MinGW (this will probably work for Cygwin as well).  The
patch applies against CVS HEAD as of 9/2/2005.

In order to get the build to work, there are a few tweaks that need to be made:
   - The patch for Bug 21766 must be applied (this is apparently
incomplete but allows the build to proceed and work)
   - The call to mkdir in gcc/libgcov.c must be fixed (no patch available yet)
   - Decompile routines must be removed from gjavah (see attached gjavah.diff)

Note that in the middle of the build, I had to contend with an
i686-pc-mingw32-fastjar that wasn't where it was supposed to be.  This
may have been an environmental problem on my side and I haven't looked
into it.

Here are a few things to note:
   - There is an unrelated change in Makefile.am relating to the
version information.  My toolchain was choking on the grep pattern
"^\#".  It looked like Make was chopping the rest of the line after
the #.  I took off the -v and changed the pattern to "^[0-9]" to get
past this.
   - I have only run a couple of limited tests against the build.  The
test suite was not run.
   - java.net on MinGW may not be working.  I haven't looked into this
but did get an error trying to run something that uses it.
   - At this point the use of enable-runtime-pseudo-relocs and
auto-import are required.  The DLL build should be considered a toy
until this can be worked around.
   - By ommiting the -no-undefined flag from libgij, a warning is
generated at link time and a DLL is not built.  This is probably the
behavior that makes sense on MinGW, since having a static libgij that
pulls in a dynamic libgcj.dll makes more sense in this environment.  A
more obvious way of suppressing the DLL version of libgij would
probably be a good thing.
   - Exception handling probably does not work across dll boundaries. 
Now that the build is working, it should be easier to address this.
   - I used a new and modified version of libtool to make this work. 
The libtool.m4 and ltmain.sh that I used are attached.  Getting the
ancient libtool in the distro to work is probably possible.  I think I
got it almost all the way there with a two-liner change regarding how
the AC_LIBTOOL_WIN32_DLL macro is evaluated.  I will follow up when I
have that working.

Comments are welcome.  My goal is to get the build machinery in a
state where a standard shared build of GCJ is possible out of the box
on MinGW.  Having this in place will make it easier to address the
lurking issues in relation to how DLL's are handled on Win32.

TJ

Attachment: mingw-shared-fix.diff
Description: Binary data

Attachment: gjavah.c.diff
Description: Binary data

Attachment: libtool.m4
Description: Binary data

Attachment: ltmain.sh
Description: Bourne shell script


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]