Difference in mangling

L

lomat

Hello,

I am using VisiBroker 4.0 on RedHat 8.0 with GCC 3.2.

When I do a "nm liborb_r.so | grep _invoke", I get some output. The symbol
of my intrest is manged as below,
002f6270 T _preinvoke__12CORBA_ObjectPCc

Now when I build an app that links to liborb_r.so, and uses the _preinvoke
API, GCC mangles this symbol as follows,
U _ZN12CORBA_Object10_preinvokeEPKc

In short, (as mangling is compiler dependent) my compiler is mangling the
symbols in a way different from the compiler that was used to build the
library I am trying to link to. As a result I am getting an un-resolved
symbol error. How do I solve this?

Thanks in advance,

Loma
 
A

Andrew Koenig

lomat> In short, (as mangling is compiler dependent) my compiler is
lomat> mangling the symbols in a way different from the compiler that
lomat> was used to build the library I am trying to link to. As a
lomat> result I am getting an un-resolved symbol error. How do I solve
lomat> this?

Suppose the names happened to be mangled the same way. What makes
you think that the compiler you are using to compile your program
would use the same binary calling conventions as the compiler that
was used to build the library?
 
V

Victor Bazarov

lomat said:
I am using VisiBroker 4.0 on RedHat 8.0 with GCC 3.2.

When I do a "nm liborb_r.so | grep _invoke", I get some output. The symbol
of my intrest is manged as below,
002f6270 T _preinvoke__12CORBA_ObjectPCc

Now when I build an app that links to liborb_r.so, and uses the _preinvoke
API, GCC mangles this symbol as follows,
U _ZN12CORBA_Object10_preinvokeEPKc

In short, (as mangling is compiler dependent) my compiler is mangling the
symbols in a way different from the compiler that was used to build the
library I am trying to link to. As a result I am getting an un-resolved
symbol error. How do I solve this?

Name mangling is compiler-specific. If two different compilers are
used to build the library and the executable, they (the library and
the executable) are not guaranteed to be compatible. C++ is only
portable on the source code level. There are two ways to solve your
problem: recompile both the library and the executable using the
same compiler OR build some kind of interface guaranteed not to have
its name mangled, e.g. by declaring it 'extern "C" '.

Victor
 
L

lomat

- I do not have source code for liborb_r.so (it comes with Borland
VisiBroker) and we have purchased it.
- There's a problem with writing a bridge. I am not sure if I can explain it
well. *I do not know all the functions that my application will use from
this library*. It's a CORBA thing. For e.g. the function _preinvoke() I
mentioned in my earlier example isn't being called from my code directly. I
call some API which (I think) in turn call this _preinvoke() internally.

Any other suggestions? Thanks!

Loma
 
L

lomat

This didn't strike me earlier, I am not a compiler internals pro yet.
You have any possible solution(s) ?

Loma
 
R

Rolf Magnus

lomat said:
- I do not have source code for liborb_r.so (it comes with Borland
VisiBroker) and we have purchased it.
- There's a problem with writing a bridge. I am not sure if I can
explain it well. *I do not know all the functions that my application
will use from this library*. It's a CORBA thing. For e.g. the function
_preinvoke() I mentioned in my earlier example isn't being called from
my code directly. I call some API which (I think) in turn call this
_preinvoke() internally.

Any other suggestions? Thanks!

Either find out which compiler the library was compiled with and use the
same one or ask the manufacturer if he can compile the library with
your compiler.
 
S

Shane McDaniel

There really isn't any other good way than recompiling everything with
the same compiler. The problem is that compilerss are not required to
name mangle the same, and therefor you can not gaurante that object code
from two different compilers will work. In fact g++ 3.1 and g++ 3.2
object code isn't even compatible, so it's not just different compilers
but possible different versions too.
 
A

Andrew Koenig

Victor> There are two ways to solve your problem: recompile both the
Victor> library and the executable using the same compiler OR build
Victor> some kind of interface guaranteed not to have its name
Victor> mangled, e.g. by declaring it 'extern "C" '.

That second alternative doesn't necessarily work, because even
if two compilers use the same naming conventions, they might
use different calling sequences.

The only solution is to use two compilers that are known to be
mutually compatible.
 
G

Greg Comeau

build some kind of interface guaranteed not to have
its name mangled, e.g. by declaring it 'extern "C" '.

Actually, that's not guaranteed, but an implementation
detail. That said, it does seem universally implemented
as not having its name mangled.
 
G

Greg Comeau

Actually, that's not guaranteed, but an implementation
detail. That said, it does seem universally implemented
as not having its name mangled.

Which I should also point out does not guarantee that
the function can still be called. After all, not even
two C compilers may be able to call it, so there is
certainly no requirement that a C++ compiler must be
able to. So tred cautiously, and be aware of the
compilers, their options settings, and what the respective
vendors say about this.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top