Re: Patch to enable libgcj.dll for MinGW

[Terry Laurenzo <tlaurenzo at gmail dot com>]

> 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.
See the thread http://gcc.gnu.org/ml/java/2005-08/msg00064.html .  It
is my opinion that the patch for gjavah is in the best interests of
everyone for all platforms.  I will break it out and submit it
separately if necessary.

> Also, we
> can't change ltdl.h directly - you need to figure out why the LT_SCOPE
> macro isn't defined correctly.
There seems to be some explanation of this issue at
http://lists.gnu.org/archive/html/libtool/2001-12/msg00040.html . 
Unfortunately, it doesn't seem like the intervening 4 years have seen
any "fix".  We can probably do something in the GCJ configury scripts
to configure libltdl to only build non-PIC code for mingw, which would
work around the problem without modifying libltdl source code.  This
should be ok since libltdl is only being relied on for rudimentary
abstraction of loading dlls and getting member names, etc.

> Are you intending for this patch
> to be applied to cvs libgcj at some point?
Yes.  I'm mailing the copyright assignment forms in today.

Are we "allowed" to patch libtool.m4 in the root directory.  There is
a bug in the ancient version of the script which is being used that
keeps the AC_LIBTOOL_WIN32_DLL from being evaluated properly.

TJ

On 9/6/05, Bryce McKinlay <mckinlay@redhat.com> wrote:
> 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:
> 
> 
> 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
> >
> 
>