[Mingw-users] Basic Java/JNI DLL Questions

[<jr...@ei...>]

I have a conventionally architected app which has a java GUI
supported by a relatively large conventional C library.  That
lib, in turn, is built from a variety of static libs in our
environment, a few objects of it's own, and some pretty ordinary
OS run-time support.  This all works pretty well for a number of
Unix environments.

Enter windows/mingw...

For starters, many thanks to those who contributed to mingw.  If
it works for me, it will save us a huge investment in a Unix
development environment (and probably more so in the staff that
know how to use it!).

I installed mingw as a cross compiler hosted on a conventional
Sun host (gcc 2.95.2/binutils 19990818).  I have been able to
build static executables which test our system at a component
level very nicely, and they run without any difficulty whatever
on NT.  Further, I was able to augment the host JDK build
environment with the win32 specific "jni.h"/"jni_md.h" to
obtain that support.  My problems appear to be entirely with
the linkage/building of the DLL proper.

I was most confused by the various DLL/SO postings and documents,
but now believe that most of that information is moot (if not
also obsolete) since the DLL client is the JVM.  I expect that I
should be able to just use "ld -shared" to link the DLL.  This
seems to do pretty well, as it finds all of my internal linkages,
but it lacks for the various system/OS calls.  I added "-lmsvcrt"
to the link procedure and this cleaned out a lot of the undefined
symbols, though a number remain (all seemingly system run-time).

My questions:

   - Is this generally the right procedure to build a DLL for
     use with java/JNI?

   - Random guessing is not a great way to determine what
     libraries I should have on the link line.  Is there a nice
     way to specify the default libraries that one normally gets
     when building a static executable?

   - What passes for the currently/nearly up-to-date set of
     cook-books/docs on this process?  Most of what I'm finding
     talks about dllwrap, but that is also indicated as
     deprecated.

Thanks!

							-jrm