libgcj.dll on MinGW

[Danny Smith]

References: <http://gcc.gnu.org/ml/java/2005-08/msg00136.html>

tj at laurenzo dot org  wote

> My local changes to libtool included the following:

>    - 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).

Native windows exe's (including ld.exe  built by mingw) don't understand
symlinks.. What actually did native ld say when you gave it a symlink.
cygwin1.dll dependent exes can use  symlinks

> My changes to the Makefile include:

>    - Add the flag -Wl,--enable-runtime-pseudo-reloc to grmic, grmiregistry
> and gcj_dbtool

Relying on --enable-auto-export and --enable-runtime-pseudo-reloc can be
dangerous, if you are importing read-only data structures, but it sounds like
you've been lucky so far
Search the cygwin mailing list archives for some discussion of this issue


>    - 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.

Right.  There are ways around that, but  why bother.

>    - 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.
>

Use dlltool  --export-all --output-def,libgcj.def libgcj0_convenience.a
This will also mark DATA symbols

Actually, why do you need a def file anyway?

Danny