Re: libgcj.dll on MinGW

[tj at laurenzo dot org]

I would like to followup to yesterday's email with some specifics as to
what I found to work in enabling dll building for MinGW.

As to the status, the application of these instructions allowed me to
produce working versions of the standard tools in the libjava
distribution, all linked against the dll instead of the static library. 
Sizes look good:
   grmic.exe  4096
   grmiregistry.exe 4096
   gij.exe 8704
   jv-convert.exe 4096
All but jv-convert seem to be working.  By working I mean that grmic
produces a help screen, netstat shows grmiregistry listening on port 1099,
and gij runs java classes.

Note that I have not made any steps to include the patches that Mohan
listed for enabling exception handling across DLL boundaries.  Also, my
version of ld on Windows is crashing when I try to compile a Java source
file to an EXE.  I haven't looked into this, but it definitely seems to
work on my Linux host using the cross tool chain from the libjava build
(illustrated by the above working programs).

So here's the basic steps I took (not including the endless fumbling
around and crash-course reading excersises about the internals of PE
files):


First, I upgraded libtool in the gcc root directory to the latest.  I
realize that this is probably taboo and has consequences beyond my sphere
of influence (which isn't very big).  However, I don't anticipate that
this will be an absolutely necessary step since the changes I made can be
applied to the old version of libtool with a little effort.  Some guidance
on the politics here would be welcome.

My local changes to libtool included the following:
   - Hardcode the compiler_c_o flag for GCJ. Libtool in the GCC source
code already seems to handle this correctly.
   - Remove link commands to generate import libraries and use a symlink
from the actual dll instead (ie.  libgcj.dll.a is no longer an import
library but a link from libgcj-6.dll).  This leverages the ability of
GNU LD for MinGW/Cygwin to use an unstripped DLL directly as an import
library. Note that this completely removes the very memory intensive
import library creation step and also solves a number of problems with
exports.  There is no more need to have 1GB of memory to create the
shared lib with this approach.
   - Changed the allow_undefined flag for MinGW targets to "no".  This
really doesn't need to be changed in libtool as there is a flag that
should make its way into the Makefile that does this.

My changes to the Makefile include:
   - Add -lws2_32 to the required libraries for building libgcj
   - Add the flag -Wl,--enable-runtime-pseudo-reloc to grmic, grmiregistry
and gcj_dbtool
   - Change gij.exe to not link against libgij but to include gij.cc
directly.  It seems that MinGW startup libraries aren't too happy about
having a main function that really lives in a DLL.
   - Add the flag -Wl,libgcj.def to the link command for building
libgcj.la.  The def file is naively generated using a Perl script that
does an nm on libgcj0_convenience.a, extracting the symbol names of
type T, B and D.  The leading underscore is removed from the name and
the result is written to the def file.  I am currently doing this step
manually but it belongs in the build.


If anyone sees any major flaws in what I am doing or has thoughts, please
share them.

TJ