Linker name conflicts due to optimization in gjavah

Thu Aug 18 06:16:00 GMT 2005

[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/