«

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

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,

"lomat" <> wrote...
> 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

- 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" <> wrote in message
news:...
> "lomat" <> wrote...
> > 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
>
>

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

Loma

"Andrew Koenig" <> wrote in message
news:...
> 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,

lomat wrote:

> - 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.

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:
>
> - 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> 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,

In article <>,
Victor Bazarov <> wrote:
>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.
--
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?

In article <bg6k36$6fc$>,
Greg Comeau <> wrote:
>In article <>,
>Victor Bazarov <> wrote:
>>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.

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?