header file inline causing problems

[Steve Pribyl]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4706 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050407/26ec4f7f/attachment.bin>