Name-mangling standard?

T

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?
 
T

Thomas Matthews

Tim said:
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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top