Re: Linker name conflicts due to optimization in gjavah

[Danny Smith <dannysmith at clear dot net dot nz>]

----- Original Message -----
From: "Ranjit Mathew"
<Sent: Thursday, 18 August 2005 18:17
Subject: Re: Linker name conflicts due to optimization in gjavah


> [CC-ing Danny for his insights.]
>
> Terry Laurenzo wrote:
> > When linking an executable that users java/util/logging/Logger, I get
> > a a linkage error:
> >
> > ------------  Linkage error ------------
> >
l:/gcc_native/i686-pc-mingw32/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../libg
cj.a(natLogger.o)(.text$_ZN4java4util7logging6Logger7getNameEPNS_4lang6StringEv[
java::util::logging::Logger::getName(java::lang::String*,
> > void)]+0x0):natLogger.cc: multiple definition of
> > `java::util::logging::Logger::getName(java::lang::String*, void)'
> >
l:/gcc_native/i686-pc-mingw32/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../libg
cj.a(Logger.o)(.text+0x950):Logger.java:
> > first defined here
> > collect2: ld returned 1 exit status
> > ------------ End linkage error --------
> >
> > I traced this down to a problem in gjavah.c.  For simple getter
> > methods it generates code like this (extracted from generated
> > Logger.h):
> >      virtual ::java::lang::String *getName () { return name; }
> >
> > Note that this is a virtual inline method declaration, which means
> > that if you declare a CNI class that includes the generated header, it
> > will errantly create a virtual method in the object file that can
> > conflict with the method declared in the corresponding Java class.
>
> You might want to see #pragma interface/implementation:
>
>   http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Interface.html
>
> The backup (non-inlined) copy is emitted as a weak symbol and
> should not normally cause linking errors. Perhaps the stock FSF
> binutils' ld does not (yet) have proper support for weak symbols
> on MinGW. See if this patch:
>

Actually, it should be emitted as a link-once COMDAT symbol the way  C++ inlines
are..
The PE_COFF link-once sematics are tried and true.  No need for latest binutils.

Weak definitions are not really supported  in PE-COFF.  Weak externals are
supported.

I wouldn't go down the pragma #interface/implementation road  Unless it is done
carefully, it can really mes up dllimport/dllexport.

I would like to help more, but unfortunately I haven't been able to buiild
libgcj natively on my humble windows box (XP. Athlon 2000, 512 MB phys mem)  for
months.
Danny