Re: unable to create the pointer object of a class at run-time (gcc weak linking of object)
On 2010-11-23 11:05:49 -0500, Jorgen Grahn said:
On Mon, 2010-11-22, rippul wrote:
Hi,
Here is my problem,
Our project is initially written in C due to making compatibility with
the 3rd party API that we are using.
Odd; C++ code can use pretty much the same libraries as C code can.
Well, yes, if it's properly configured. See below.
Later on due to addition of new features developers added these
features in C++ code. Hence we converted all of our C file to CPP
You mean C++ here, not CPP (the C pre-processor).
No, almost certainly CPP, the file extension.
...
I have attached the output of the nm command (nm -a * *.a | grep
CAccessLog)
...
000001e0 T _ZN10CAccessLog13getLogMessageEv
00000080 T _ZN10CAccessLog14getSignMessageEv
...
I am also some confused by this kind of the output that I cant
understand easily.
It is called "name mangling" and is a method for making C++ compatible
with general-purpose linkers. Your nm probably has an option for
decoding such names and making them eminently readable! Read the
manual.
Of course, that won't solve the problem.
Sounds like the "3rd party API" (is that different from a "library"?)
is written in C. To call it from C++, the C++ code has to know that.
Each function has to be marked 'extern "C"'.
C interface:
void f();
int g();
C++ interface:
extern "C" void f();
extern "C" int g();
Alternative C++ interface:
extern "C" {
void f();
int g();
}
That last one is the most common approach. It has to be done in the C
header. Don't try to put #include directives inside an extern "C"
block; this will often lead to mysterious problems.
#ifdef __cplusplus
extern "C" {
#endif
void f();
int g();
#ifdef __cplusplus
}
#endif
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)