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 "EntLogToStrings(int)"
function is mangled by g++ to "_Z14EntLogToStrings", but the symbol in
the *.so library is "__1cOEntLogToString6Fh_pkc_". The
GetConstructorError() member function of the EntFile object seems to
become "_ZN7EntFile19GetConstructorErrorEv" fro g++ but
"__1cHEntFileTGetConstructorError6M_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 "EntLogToStrings(int)"
function is mangled by g++ to "_Z14EntLogToStrings", but the symbol in
the *.so library is "__1cOEntLogToString6Fh_pkc_". The
GetConstructorError() member function of the EntFile object seems to
become "_ZN7EntFile19GetConstructorErrorEv" fro g++ but
"__1cHEntFileTGetConstructorError6M_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 */ __1cOEntLogToString6Fh_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.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book