This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Patch to enable libgcj.dll for MinGW
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?).
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.
TJ