Re: Patch to enable libgcj.dll for MinGW

[TJ Laurenzo <tlaurenzo at gmail dot com>]

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.
> >
> 
>