Patch to enable libgcj.dll for MinGW

Thu Sep 8 10:22:00 GMT 2005

TJ Laurenzo writes:
 > Ok. I figured it out. This is an interaction between objects
 > produced with g++ and gcj. My original recommendation to take this
 > optimization out still holds as a result of this test on the grounds
 > that what we are asking the compilers to do is not equivilent to
 > simple inlining in a pure C++ program. Further, I see no clear way to
 > make gcj output the "correct" code without some pretty nasty hacks.
OK, thanks for diagnosing this.
 > Now, this happens to work fine on Linux ld and the like because
 > what we have is a declaration with strong linkage held up to one
 > with weak linkage. The linker discards the one with weak linkage
 > and all is well.
Which is, happily, precisely the semantics we want. 
Mingw defines SUPPORTS_WEAK but doesn't correctly support weak
semantics. This is a bug in the Mingw toolchain, not a bug in gcj.
 > However on Windows, what we have is one declaration defined as a
 > COMDAT and one as a standard text definition. To the linker these
 > are distinct. The only way it would merge the two would be if both
 > were defined as a COMDAT, as would be the case if this had been a
 > standard C++ program where myclass.cc included the myclass.h header
 > along with its inline definitions.
 > 
 > In fact, compiling this on mingw using the CVS HEAD compiler produces
 > the following:
 > -----------------------
 > M:\tmp\comdatinline\win32>g++ -c -o myclass.o myclass.cc
 > M:\tmp\comdatinline\win32>g++ -c -o natmyclass.o natmyclass.cc
 > M:\tmp\comdatinline\win32>g++ -o test.exe myclass.o natmyclass.o
 > natmyclass.o(.text$_ZN7myclass12getSomeFieldEv[myclass::getSomeField()]+0x0):natmyclass.cc:
 > multiple definition of `myclass::getSomeField()'
 > myclass.o(.text+0x0):myclass.cc: first defined here
 > collect2: ld returned 1 exit status
 > ===end===
 > 
 > Which is exactly what happens to natLogger.cc when building libjava. 
 > So, can we just ditch this entire optimization as my first patch did? 
 > Even on Linux, gcjh is causing the compilers to produce non-standard
 > code. It just so happens that it is benign in that case whereas it is
 > a show-stopper for PE targets that use COMDAT to implement vague
 > linkage.
Right, so we should disable it on PE targets. Please submit a patch
that does so.
Andrew.