Difference in mangling

Discussion in 'C++' started by lomat, Jul 29, 2003.

  1. lomat

    lomat Guest

    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, Jul 29, 2003
    #1
    1. Advertising

  2. 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,
    Andrew Koenig, Jul 29, 2003
    #2
    1. Advertising

  3. "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
    Victor Bazarov, Jul 29, 2003
    #3
  4. lomat

    lomat Guest

    - 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
    >
    >
    lomat, Jul 29, 2003
    #4
  5. lomat

    lomat Guest

    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, Jul 29, 2003
    #5
  6. lomat

    Rolf Magnus Guest

    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.
    Rolf Magnus, Jul 29, 2003
    #6
  7. 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
    >
    Shane McDaniel, Jul 29, 2003
    #7
  8. 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,
    Andrew Koenig, Jul 29, 2003
    #8
  9. lomat

    Greg Comeau Guest

    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?
    Greg Comeau, Jul 29, 2003
    #9
  10. lomat

    Greg Comeau Guest

    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?
    Greg Comeau, Jul 29, 2003
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. abhijeet.s
    Replies:
    8
    Views:
    4,411
    Jean-Francois Briere
    Feb 3, 2006
  2. sunny

    Name Mangling in DDK

    sunny, Jul 9, 2004, in forum: C++
    Replies:
    4
    Views:
    444
    Robert Wessel
    Jul 10, 2004
  3. Tim Slattery

    Name-mangling standard?

    Tim Slattery, Sep 2, 2004, in forum: C++
    Replies:
    1
    Views:
    1,829
    Thomas Matthews
    Sep 2, 2004
  4. Randy Yates
    Replies:
    2
    Views:
    512
    Randy Yates
    Jan 4, 2005
  5. Daniele Varrazzo
    Replies:
    0
    Views:
    261
    Daniele Varrazzo
    Jul 19, 2004
Loading...

Share This Page