Re: Patch to enable libgcj.dll for MinGW

[Bryce McKinlay <mckinlay at redhat dot com>]

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