Patch to enable libgcj.dll for MinGW

Wed Sep 7 15:35:00 GMT 2005

TJ Laurenzo writes:
 > As has been pointed out earlier, this situation really *should* work,
 > regardless of whether it is generally useful or not. According to
 > Danny, PE binutils supports the necessary semantics to make this work
 > with the caveat that it might screw up dllimport/dllexport. Yet it
 > seems that the c++ compiler is not emitting code that defines these
 > symbols appropriately. Here is the output from nm on natLogger.o
 > built for mingw. I am only showing the lines that relate to the
 > getName method:
 > ----------------------
 > 00000000 t .text$_ZN4java4util7logging6Logger7getNameEPNS_4lang6StringEv
 > U __ZN4java4lang5Class7getNameEPNS0_6StringEv
 > 00000000 T __ZN4java4util7logging6Logger7getNameEPNS_4lang6StringEv
 > ----------------------
 > This is clearly not correct, but can anyone point out how this should
 > look for a PE object?
 > 
 > This is starting to look like a C++ compiler bug. When I get a
 > moment, I'll distill this down to a simple example and shoot it over
 > to the appropriate place (can anyone tell me where that is?).
gcc@gcc.gnu.org
 > Still, Danny does mention that relying on #pragma
 > interface/implementation usage to eliminate inlines for PE targets
 > can screw up dll imports and exports. Can anyone provide any
 > elaboration about what the issues with dll import/export might be?
 > Since this is exactly what I am aiming for, I would like to have a
 > way to disable the generation of these optimization inlines
 > produced by gcjh, possibly through an argument. Would anyone be
 > opposed? Since gcjh is performing optimizations, it seems only
 > natural that there be a switch to turn that behavior off,
 > regardless of the reason.
No, I don't think so. What you're talking about is a new gcjh option
to workaround a bug in another part of the toolchain. While I'm not
totally opposed to that, it doesn't strike me as a great idea.
However, there is one compromise that doesn't require a new gcjh
option and it doesn't require gcjh to generate different code for
mingw targets. You could change gcj to generate something like
#ifdef CYGWIN_BROKEN_LD
 virtual jint getFoo ();
#else
 virtual jint getFoo () { return foo; }
#endif
which would do the Right Thing for mingw/cygwin, and wouldn't bother
anyone else.
Andrew.