problems in C functions call C++

problems in C functions call C++

[Tian Dale-A19565]

Dear Sir/Madam:

I encountered a tough situation:

In my code have both c & c++ source code, some functions in c code call functions in c++, and vice versa.

First I compiled the code using gcc compiler to a dynamic library(.so), it's okay.  But when I changed compiler to arm gcc( version listed below:

(arm_v6_vfp_le-gcc (GCC) 3.4.3 (MontaVista 3.4.3-25.0.7.custom 2005-05-22)

Copyright (C) 2004 Free Software Foundation, Inc.)

Something happens to the functions implemented in C++ code, and called by C functions.  When I look the symbol table of .so(using nm tool), I found some differences between .so compiled with gcc and that compiled with arm gcc.  Functions (mentioned above, implemented in C++, called by C) were unresolved, that means the linker cannot locate the implementation of those functions.

Could you help me to solve this problem?  If the problem I did not describe clearly, I'll give more details.

 

Thank you.

 

Best regards,

Dale Tian

Global Software Group, Motorola China

No. 108, Jian Guo Road

Chao Yang District

Beijing 100022

P.R.China

============================

General Business Information

Re: problems in C functions call C++

[Joe Buck]

On Sat, Sep 17, 2005 at 01:01:03AM +0800, Tian Dale-A19565 wrote:
> I encountered a tough situation:

Please, never send messages to both gcc and gcc-help.  gcc-help would
have been the right list, except for:

> (arm_v6_vfp_le-gcc (GCC) 3.4.3 (MontaVista 3.4.3-25.0.7.custom 2005-05-22)

That is not an FSF release; you'll need to go to MontaVista for any
questions about which FSF release their custom release is link-compatible
with.

Re: problems in C functions call C++

[Mike Stump]

On Friday, September 16, 2005, at 10:01  AM, Tian Dale-A19565 wrote:
> Functions (mentioned above, implemented in C++, called by C) were 
> unresolved, that means the linker cannot locate the implementation of 
> those functions.
>
> Could you help me to solve this problem?

The ability to answer is dependent upon the quality of the question.  
If you case you removed all details that allow anyone from helping you.

Compare your question to:

When I compile:

extern "C" void foo() {
}

I get:

.public foo
foo:
	ret

at -O2 using gcc 3.4.3 on arm-elf and when I assemble this with 
binutils 2.904, nm shows no foo in the symbol table, is the compiler 
broken?

Here we see the input to the compiler, the output from the compiler, 
the compilation flags used and so on...  That has an answer, and it is 
no; further, we could say that as from binutils appears to be broken, 
and then have you go ask the binutils people about it.

So, cut down the testcase to a small example, show us the full source 
code (gcc -E), the flags used to compile, the .s file produced and the 
name of the symbol in question...

RE: problems in C functions call C++

[Tian Dale-A19565]

Hi, Mike:
Thank you for your help.  According to your suggestion, I wrote a simple example and found the cause of the problem.  I used "ar" to archive the library, not "arm ar".  "ar" cannot build right symbol tables for arm objs.
Now I use "arm ar", while linking, symbols can be correctly located.

Thank you again.
Best regards,
Dale

-----Original Message-----
From: Mike Stump [mailto:mrs@apple.com] 
Sent: 2005年9月16日 12:57
To: Tian Dale-A19565
Cc: gcc-help@gcc.gnu.org
Subject: Re: problems in C functions call C++

On Friday, September 16, 2005, at 10:01  AM, Tian Dale-A19565 wrote:
> Functions (mentioned above, implemented in C++, called by C) were 
> unresolved, that means the linker cannot locate the implementation of 
> those functions.
>
> Could you help me to solve this problem?

The ability to answer is dependent upon the quality of the question.  
If you case you removed all details that allow anyone from helping you.

Compare your question to:

When I compile:

extern "C" void foo() {
}

I get:

.public foo
foo:
	ret

at -O2 using gcc 3.4.3 on arm-elf and when I assemble this with 
binutils 2.904, nm shows no foo in the symbol table, is the compiler 
broken?

Here we see the input to the compiler, the output from the compiler, 
the compilation flags used and so on...  That has an answer, and it is 
no; further, we could say that as from binutils appears to be broken, 
and then have you go ask the binutils people about it.

So, cut down the testcase to a small example, show us the full source 
code (gcc -E), the flags used to compile, the .s file produced and the 
name of the symbol in question...