Name-mangling standard?

[Tim Slattery]

Does the C++ language standard mandate a particular name-mangling
method?

I'm trying to use the Entrust toolkit to create a C++ program that
encrypts and decrypts files. Entrust supplies header files defining
their objects and functions, and *.so files (I'm on a Sun Sparc
machine running Solaris) containing the implementation of the
functions.

I'm compiling with the GNU g++ compiler. According to the
documentation the *.so files were made with Sun's C++ compiler. The
compilation phase goes fine, but I get "undefined symbol" errors in
the link step.

Using the "nm" utility seems to show that the "EntLogToString s(int)"
function is mangled by g++ to "_Z14EntLogToSt rings", but the symbol in
the *.so library is "__1cOEntLogToS tring6Fh_pkc_". The
GetConstructorE rror() member function of the EntFile object seems to
become "_ZN7EntFile19G etConstructorEr rorEv" fro g++ but
"__1cHEntFileTG etConstructorEr ror6M_h_" in the Sun generated library.

Is one or the other compiler violating a standard, or is there no
standard and they're both making it up? And in either case, is there a
way to work with this?

--
Tim Slattery
Sl********@bls. gov

[Thomas Matthews]

Tim Slattery wrote:

Does the C++ language standard mandate a particular name-mangling
method?

I'm trying to use the Entrust toolkit to create a C++ program that
encrypts and decrypts files. Entrust supplies header files defining
their objects and functions, and *.so files (I'm on a Sun Sparc
machine running Solaris) containing the implementation of the
functions.

I'm compiling with the GNU g++ compiler. According to the
documentation the *.so files were made with Sun's C++ compiler. The
compilation phase goes fine, but I get "undefined symbol" errors in
the link step.

Using the "nm" utility seems to show that the "EntLogToString s(int)"
function is mangled by g++ to "_Z14EntLogToSt rings", but the symbol in
the *.so library is "__1cOEntLogToS tring6Fh_pkc_". The
GetConstructorE rror() member function of the EntFile object seems to
become "_ZN7EntFile19G etConstructorEr rorEv" fro g++ but
"__1cHEntFileTG etConstructorEr ror6M_h_" in the Sun generated library.

Is one or the other compiler violating a standard, or is there no
standard and they're both making it up? There is no standard for name mangling. Name mangling is up to the
compiler implementer, as you have found out. And yes, they are both
making it up.

And in either case, is there a way to work with this?

Yes, either use the compiler tools they did or obtain a library
from them that was built using the Gnu g++ compiler.

You _may_ be able to declare an extern C function with the
mangled name in the library:
extern "C"
{
/* return type */ __1cOEntLogToSt ring6Fh_pkc_(/*...*/);
}

You may have to remove the leading underscores, depending on
how G++ translates the filename. This workaround will not
work for member function, as the C language has no definition
for member functions.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book