Re: header file inline causing problems

[Steve Pribyl <steve at netfuel dot com>]

I was able to duplicate this using both the  4.0.0 linux/mingw cross compiler 
and the mingw native compiler and the(THIS IS NEW INFO) mingw 3.4.2 compiler.

Administrator@SBUILDER /h
$ g++ j.o natj.o -lgcj -lws2_32 -liconv
natj.o(.text$_ZN1j7getNameEv+0x0): In function `ZN1j7getNameEv':
h://natj.cc: multiple definition of `j::getName()'
j.o(.text+0x1e):h://j.java: first defined here
collect2: ld returned 1 exit status

Administrator@SBUILDER /h
$ g++ -v
Reading specs from t:/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as 
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls 
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry 
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt 
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter 
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32

I have also submitted bug 20993.

Ranjit Mathew wrote:
> On Apr 8, 2005 8:21 AM, Steve Pribyl <steve@netfuel.com> wrote:
>
> > Yup that did it.
>
>
> But were you able to reproduce the
> multiple definition errors? The compiler
> seems to produce either weak symbols
> or symbols in "linkonce" sections for
> such cases, neither of which should
> produce multiple definition errors (as
> far as I can tell).
>
> If you're building from stock FSF
> sources for both GCC and binutils
> and you're able to reproduce this
> problem, please file a bug in the 
> GCC bugzilla and attach your
> testcase.
>
> If possible, try it out with an older
> GCC (3.4 or 3.3) and if you're not
> able to reproduce it, do mark the
> bug as "[4.0 regression]".
>
> Thanks,
> Ranjit.
>
>
>
> > [steve@pascal steve]$ cat natj.cc
> > #pragma implementation "j.h"
> > #include "j.h"
> >
> > int main(int argc,char** argv)
> > {
> >         j *bob=new j();
> >         bob->getName();
> >         return 0;
> > }
> >
> > [steve@pascal steve]$ i386-mingw32msvc-nm natj.o
> >          U __alloca
> > 00000000 b .bss
> > 00000000 d .data
> >          U __Jv_AllocObject
> > 00000000 T _main
> >          U ___main
> > 00000000 t .text
> > 00000000 t .text$_ZN1j7getNameEv
> >          U __ZN1j6class$E
> > 00000000 T __ZN1j7getNameEv
> >          U __ZN1jC1Ev
> >
> > [steve@pascal steve]$ cat j.java
> > class j
> > {
> >         String _name;
> >         j() {
> >                 _name="BOB";
> >         }
> >         String getName() {
> >                 return _name;
> >         };
> > }
> >
> > [steve@pascal steve]$ i386-mingw32msvc-nm j.o
> > 00000000 b .bss
> > 00000094 d __catch_classes_j
> > 00000088 d __CD_j
> > 00000090 d __CT_j
> > 00000000 d .ctors
> > 00000000 d .data
> > 00000000 d __FL_j
> > 00000044 t __GLOBAL__I_0__ZN1jC1Ev
> >          U __Jv_RegisterClass
> >          U __Jv_ThrowNullPointerException
> > 00000020 d __MT_j
> > 00000000 r .rdata
> > 00000000 N .stab
> > 00000000 N .stabstr
> > 00000000 t .text
> > 00000000 r __Utf1
> > 0000000a r __Utf2
> > 00000016 r __Utf3
> > 0000001e r __Utf4
> > 0000002a r __Utf5
> > 00000044 r __Utf6
> > 0000004c r __Utf7
> > 000000c0 D __ZN1j6class$E
> > 0000002c T __ZN1j7getNameEv
> > 00000000 T __ZN1jC1Ev
> >          U __ZN4java4lang6Object5cloneEv
> >          U __ZN4java4lang6Object6class$E
> >          U __ZN4java4lang6Object6equalsEPS1_
> >          U __ZN4java4lang6Object8finalizeEv
> >          U __ZN4java4lang6Object8hashCodeEv
> >          U __ZN4java4lang6Object8toStringEv
> >          U __ZN4java4lang6ObjectC1Ev
> >          U __ZN4java4lang6String6class$E
> > 00000060 D __ZTVN1jE
> >          U __ZTVN4java4lang5ClassE
> >
> > j.h is generated by gcjh.
> >
> > Steve
> > Ranjit Mathew wrote:
> >
> > > Steve Pribyl wrote:
> > >
> > >
> > > > I don't think I am going be able to duplicate this using the cross-compiler.
> > > > I have created a simple test case.  Since the cross compiler does not have a
> > > > libgcj.a, I have hacked in the one created by the cross compilier. This libgcj.a
> > > > still has this problem but this test case does not bring out the problem.
> > > >
> > > > Is there anything else I can do to figure/help figure this out.  Is seems that
> > > > it might be specific to building the compiler.
> > >
> > >
> > > I think "#pragma interface/implementation" is the key.
> > >
> > > Try putting "#pragma interface" in the header file ("j.h"?).
> > >
> > > Try putting "#pragma implementation" in the implementation
> > > file ("natj.cc"?).
> > >
> > > #include "j.h" in another file, say "main.cc" and use
> > > the "getName()" method there.
> > >
> > > HTH,
> > > Ranjit.
> >
> > --
> > Steve Pribyl
> > Steve AT NetFuel dot com
> > Computer Infrastructure Practitioner

--
Steve Pribyl
Steve AT NetFuel dot com
Computer Infrastructure Practitioner

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature