Difference in mangling

[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__12C ORBA_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_Obje ct10_preinvokeE PKc

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

[Victor Bazarov]

Re: Difference in mangling

"lomat" <atambe@ideas.c om> wrote...[color=blue]
> 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__12C ORBA_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_Obje ct10_preinvokeE PKc
>
> 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?[/color]

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

[Andrew Koenig]

Re: Difference in mangling

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?

--
Andrew Koenig, ark@acm.org

[lomat]

Re: Difference in mangling



- 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

"Victor Bazarov" <v.Abazarov@att Abi.com> wrote in message
news:vid1a82k62 ii9f@corp.super news.com...[color=blue]
> "lomat" <atambe@ideas.c om> wrote...[color=green]
> > 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[/color][/color]
symbol[color=blue][color=green]
> > of my intrest is manged as below,
> > 002f6270 T _preinvoke__12C ORBA_ObjectPCc
> >
> > Now when I build an app that links to liborb_r.so, and uses the[/color][/color]
_preinvoke[color=blue][color=green]
> > API, GCC mangles this symbol as follows,
> > U _ZN12CORBA_Obje ct10_preinvokeE PKc
> >
> > In short, (as mangling is compiler dependent) my compiler is mangling[/color][/color]
the[color=blue][color=green]
> > 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?[/color]
>
> 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
>
>[/color]

[lomat]

Re: Difference in mangling

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

Loma

"Andrew Koenig" <ark@acm.org> wrote in message
news:yu99lluh76 v6.fsf@tinker.r esearch.att.com ...[color=blue]
> 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?
>
> --
> Andrew Koenig, ark@acm.org[/color]

[Shane McDaniel]

Re: Difference in mangling


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.

lomat wrote:[color=blue]
>
> - 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
>[/color]

[Rolf Magnus]

Re: Difference in mangling

lomat wrote:
[color=blue]
> - 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![/color]

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.

[Andrew Koenig]

Re: Difference in mangling

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.

--
Andrew Koenig, ark@acm.org

[Greg Comeau]

Re: Difference in mangling

In article <vid1a82k62ii9f @corp.supernews .com>,
Victor Bazarov <v.Abazarov@att Abi.com> wrote:[color=blue]
>build some kind of interface guaranteed not to have
>its name mangled, e.g. by declaring it 'extern "C" '.[/color]

Actually, that's not guaranteed, but an implementation
detail. That said, it does seem universally implemented
as not having its name mangled.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

Re: Difference in mangling

In article <bg6k36$6fc$1@p anix5.panix.com >,
Greg Comeau <comeau@comeauc omputing.com> wrote:[color=blue]
>In article <vid1a82k62ii9f @corp.supernews .com>,
>Victor Bazarov <v.Abazarov@att Abi.com> wrote:[color=green]
>>build some kind of interface guaranteed not to have
>>its name mangled, e.g. by declaring it 'extern "C" '.[/color]
>
>Actually, that's not guaranteed, but an implementation
>detail. That said, it does seem universally implemented
>as not having its name mangled.[/color]

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.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?