Linker name conflicts due to optimization in gjavah

[Ranjit Mathew]

[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/../../../libgcj.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/../../../libgcj.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:

  http://sourceware.org/ml/binutils/2004-06/msg00068.html

against binutils helps you.

Beyond this, Danny should be the right person to provide an
insight into why this could not be working on MinGW.

HTH,
Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/