Patch to enable libgcj.dll for MinGW

[Danny Smith]

----- Original Message -----
From: "Andrew Haley"
Sent: Thursday, 8 September 2005 03:52


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