libgcj, Win32 & dll's

[Jeff Sturm <jsturm at sigma6 dot com>]

Having reached a point where I can benefit from a native Win32 port of
libgcj, I scanned the archives to see what had been done... apparently
nothing that is complete, ready, tested.  There was/is a web site for
libgcj on Win32, though it appears to be unreachable.

So I built a native (i686-mingw32) Win32 GCC toolchain successfully,
with the Java frontend and Win32 thread support.  I proceeded to build
libgcj.  The java.lang and java.io stuff all built with minor changes
(benefitting from the fact that CRTDLL.DLL is somewhat POSIX-ish). 
Threads and java.net need more work, and I haven't yet tried boehm-gc
(which _should_ handle Win32 out-of-the-box).  Simple Java programs now
link & execute just fine.  Everything else can probably be done without
too much effort, thanks to great work done by the GCC and Mingw32
coders.

BUT... all of libgcj is static-linked so far.  Libtool has no idea how
to build a shared library on Win32, so I attempted to convert libgcj.a
into libgcj.dll somehow, knowing nothing about DLLs in the process. 
I've since learned that Win32 DLLs require a stub library, and they
export library functions as a jump table, and data symbols via
indirection (sort of like early COFF shared libraries back in SVR3
days).

The trouble is that gcj-compiled classes share various global data
symbols, such as the vtable and class objects.  There's no way that I
can see to link Java classes in a DLL, since these data symbols are
generated internally by gcj.  C/C++ programmers work around the problem
by using the __declspec(dllimport) and __declspec(dllexport) modifiers,
which instructs gcc to generate the extra indirection code.  But there
are no similar modifiers for Java (and I certainly don't advocate
extending the language).

I'm not really sure what to do next... gcj for Win32 won't be very
useful with static linkage only.  I suppose I could move just the C/C++
portion of the runtime into a DLL, but that wouldn't shrink the
executables much.  Any other ideas?  Did I miss something obvious??

-- 
Jeff Sturm
jsturm@sigma6.com