Deja Vu: multiple definition of `java::lang::String::length()'?

Mon Mar 11 10:40:00 GMT 2002

Adam Megacz <gcj@lists.megacz.com> writes:
> How is this possible?
>> /usr/local/gcc/lib/gcc-lib/i686-pc-mingw32/3.1/../../../../i686-pc-mingw32/lib/libgcj.a(String.o): In function `ZN4java4lang6String6lengthEv':
> /home/megacz/branch/bin/i686-pc-mingw32/libjava/../../../gcc/libjava/java/lang/String.java:187: multiple definition of `java::lang::String::length()'
> /home/megacz/xwt/bin-Win32/org/xwt/plat/Win32-nat.o:/usr/local/gcc/include/gcj/cni.h:88: first defined here

I knew this looked familiar....
 http://gcc.gnu.org/ml/java/2001-11/msg00122.html
This is actually caused by gcjh -- it generates a function body for
simple functions, like this:
 jint length () { return count; }
Now this is cool, since it lets gcc inline simple methods, but OTOH it
causes link failures since you now have two definitions of
java::lang::String::length() (one in C++ from the headers, and one in
Java from String.java).
Is this only a problem on mingw due to lack of weak symbols? I haven't
tried it on any other platforms. Sticking an 'inline' in front of the
jint doesn't help, and C++ doesn't provide a way to specify internal
linkage for a method ('static' has a different meaning for methods
than for functions, AFAICT).
I'll write up a patch to fix this if somebody tells me what the proper
behavior should be.
 - a
-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'." --lynx_user_abroad
Why Windows NT/2k/XP is unreliable: www.zappadoodle.com