Re: header file inline causing problems

[Steve Pribyl <steve at netfuel dot com>]

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.

class j
{
        String _name;
        j() {
                _name="BOB";
        }
        String getName() {
                return _name;
        };
}

#include "j.h"

int main(int argc,char** argv)
{
        j *bob=new j();
        bob->getName();
        return 0;
}

But it seems to work fine.

[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

[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
         U __ZN1j6class$E
         U __ZN1jC1Ev



Steve Pribyl wrote:
> As far as I can tell.
> This seems to only be a problem when building using a Linux cross-compiler.
> I have not been able to duplicate this on native mingw or Linux.
>
> I am in the process of trying to duplicate the problem using the Linux 
> to Mingw cross compiler.
>
> Steve
>
> Tom Tromey wrote:
>
> > > > > > > "Ranjit" == Ranjit Mathew <rmathew@gmail.com> writes:
> >
> >
> >
> > Ranjit> Since natLogger.cc doesn't explicitly define getName(), I guess
> > Ranjit> this is the result of a funky interaction between using
> > Ranjit> #pragma interface/implementation and weak symbols support:
> > Ranjit>   http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Interface.html
> > Ranjit> But 4.0 should have weak symbols support for Cygwin/MinGW:
> > Ranjit>   http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00265.html
> > Ranjit> So I am confused...
> >
> > We always have the option of not generating inline method bodies when
> > generating CNI headers.  I believe what we do here isn't really valid,
> > it just always happened to work.
> >
> > Tom

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

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