Patch to enable libgcj.dll for MinGW

Wed Sep 7 22:31:00 GMT 2005

Thanks for the explanation. I am trying to distill this down to a
very simple C++ only failure case and am having difficulty reproducing
the problem outside of the libjava build. This just keeps getting
more strange. I am starting to think that it is an interaction
between object files produced by GCJ and implementations in C++. 
Something is hitting a corner case that is causing this to blow up
with duplicate definition errors on link.
> > Ranjit Mathew writes:
> > > On 9/7/05, TJ Laurenzo wrote:
> > > > 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
> > > [...]
> > > > 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?).
> > >
>>> COMDAT works fine in C++:
>> inline void foo (){};
>> compiles to this in C++:
>> .section .text$_Z3foov,"x"
> .linkonce discard
> .align 2
> .p2align 2,,3
> .globl __Z3foov
> ----
>>> objdump -x inline.o says this:
>> 3 .text$_Z3foov 00000008 00000000 00000000 000000b4 2**2
> CONTENTS, ALLOC, LOAD, CODE, LINK_ONCE_DISCARD (COMDAT
> __Z3foov 4)
>> and ld does indeed discard the duplicates.when building an exe or dl. In C++,
> inline functions, artificiall methods and artificial data are made onle only
>> User code can force link-once semantics on variables, using
> __attribute__((selectany)), but its up to the compiler to generate the
> appropriate section flags for functions
>> If you want the details on how PE-COFF vague linkage works refer to
> "Microsoft Portable Executable and Common Object File Format Specification,
> Revision 6.0, February, 1999"
>>> NT weak externals (what you get if apply __attribute__((weak)) to declaration
> of an external) do not
> really work that well when importing from a dll. "Vague" linkage from dll's is
> usualy handled with explicit dll linkage (the GetProcAddress API)
>> > > The GCC bugzilla (http://gcc.gnu.org/bugzilla/) is the place to
> > > report GCC bugs. This *could* be related to the COMDAT
> > > patches by Julian Brown, so you might want to directly bounce
> > > it off him to see if he can provide an insight into this problem.
> >
> > It's not a good idea to only post a Bugzilla entry. Talk to the gcc
> > mailing list to find out if this really should work, and if anyone
> > knows about any related problems.
> > Andrew.
> >
>>