extern C linkage on aCC6

[Steve_The_King]

hi,
I am facing a problem where I have a file main.cpp in which I have a function int abc(RequestInfo* request,BaseCommon *(*GetRequest)(RequestInfo *) /*= 0*/) {
. //My code
.
.
.
.
}

There is a header file xyz.h which includes
extern "C" {

extern int abc(RequestInfo *requestInfo, BaseCommon *(*GetRequest)(RequestInfo *) = 0);

/**
* Routines
*/
}

This xyz.h is included in main.cpp.


When I create a shared library and try to load my module I get a runtime error which gives me an error
/usr/lib/hpux64/dld.so: Unsatisfied code symbol 'abc' in load module

But when I remove the "extern C" linkage the things work fine.

Please let me what am I missing or is this the expected behaviour.

I am using hpitan 64-bit machine with aCC compiler

[James R. Ferguson]

Hi:

I would suppose that "hpitan" stands for "HP Itanium", though that's a new abbreviation on me.

Consider the poor search engines...

...JRF...

[Steven Schweda]

Have you considered the potential advantages
of supplying a complete failing test case?

> [...] I have a file main.cpp in which I
> have a function int abc([...]

So, abc() is in a C++ source file? And it
itself is not bracketed by an '"extern C"',
but its prototype is? I'm not C++-fluent,
but I don't think that I'm amazed by your
problem.

> But when I remove the "extern C" linkage
> the things work fine.

Or, I'd guess, if you add another one around
abc(). Telling the C++ compiler that you
have a C function named abc() when you
actually have a C++ function named abc()
sounds to me as if it might confuse someone.

[Dennis Handly]

>int abc(RequestInfo*,BaseCommon* (*)(RequestInfo*))

As mentioned by Steven, this isn't a good way to program. You should always be explicit with extern "C", inline, public and virtual keywords.

Your particular case is documented in the porting to aCC6 guide and has your picture on it: :-)
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801/?ciid=2708d7c682f02110d7c682f02110275d6e10RCRD
ABI-9. Mangling extern "C" names with parms of type pointer to function

>JRF: I would suppose that "hpitan" stands for "HP Itanium"

The correct term is Integrity or IPF. But the real topic should be aCC6.

>Steven: if you add another one around abc(). Telling the C++ compiler that you have a C function named abc() when you actually have a C++ function named abc() sounds to me as if it might confuse someone.

The Standard allow the first linkage spec to be inherited by the second. But there is an "if" about matching. Having pointers to C vs C++ functions causes the match to fail, unless they use a typedef in an extern "C" block.