header file inline causing problems

Mon Apr 11 06:15:00 GMT 2005

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
>>>
-- 
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/