Re: Patch to enable libgcj.dll for MinGW

[Andrew Haley <aph at redhat dot com>]

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.