Patch to enable libgcj.dll for MinGW

[Bryce McKinlay]

Terry,

Thanks for working on this - its certainly a big step forward to get a 
libgcj DLL working on mingw and cygwin. Are you intending for this patch 
to be applied to cvs libgcj at some point? If so, that would be great, 
and I have a few comments:

Could you explain the need for the gjavah changes more? Obviously, we 
couldn't apply this patch as-is with that change. Perhaps decompiling 
could be disabled conditionally for mingw/cygwin (maybe just by adding a 
command-line argument), if it can't be fixed some other way. Also, we 
can't change ltdl.h directly - you need to figure out why the LT_SCOPE 
macro isn't defined correctly.

If and when you think its ready, the patch should be submitted to 
java-patches@gcc.gnu.org with a ChangeLog entry. Since there doesn't 
seem to be an active gcj-on-windows maintainer, I think its pretty much 
your call to decide when it goes in. I wouldn't worry much about bugs 
and testsuite results at this point - having a clean patch that 
basically works should be the initial goal.

Bryce


Terry Laurenzo wrote:

>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
>