Sign in to follow this  

removing Z9[function_name]_ from shared library symbols

This topic is 4266 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

when I compile a shared library in linux with gcc al the function names get decorated with Z[number] and "_". I've read all the documentation I have about shared libs and the compiler and I can't find why the hell this happens. I'm sure this is a really stupid thing, but I've not worked with shared libraries before.

Share this post


Link to post
Share on other sites
oh. Apparently this "decorations" are called mangling... this happens because for some reason (I don't know) c++ generates the symbols like this.

If I'm not wrong, to avoid the mangling I should define this famous preprocessor line:

#ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif


Thanks God for wiki!

Share this post


Link to post
Share on other sites
C++ has to mangle names to support things like operator overloading, function overloading, and constructors and destructors (which are nameless). It mangles the fancy names into names the linker can understand. The linker only understands the sorts of names that C can generate, which are indecipherable from those that an assembler can generate.

Rule of thumb: if you're going to dlopen() a library and dlsym(), you want to use C linkage.

Share this post


Link to post
Share on other sites
Quick question: that magic preprocessor line only disables name mangling on the function definitions, so the code itself is still C++, right? So, I should be able to use libglade's XML loader & autoconnect features in C++ if I use that preprocessor line?

Share this post


Link to post
Share on other sites
Yes. All regular (global non-template) functions in an extern "C" block get C linkage but can e.g. take a C++ object as a parameter. dlsym() only gets a void* function pointer. The user still has to know the function signature. Note that global variables or constants with C linkage can be dlsym()'ed too. This can be useful for things like version numbers.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sander
Quick question: that magic preprocessor line only disables name mangling on the function definitions, so the code itself is still C++, right? So, I should be able to use libglade's XML loader & autoconnect features in C++ if I use that preprocessor line?

Just a note: The preprocessor line just checks whether the file's being compiled by a C++ or a C compiler (the __cplusplus symbol is defined for C++ compilations), and if so, C linkage is used (which is what actually prevents the C++ name mangling). If you're working exclusively in C++, you can drop the preprocessor lines and say:
extern "C"
{
// functions go here
}

Share this post


Link to post
Share on other sites
@Muhammad: I know that, but I had a problem a few weeks back using libglade, the XML-UI library for GTK. When I created a C++ project and tried to load glade XML files, libglade could not connect the GTK signals to my signal handlers. I'm thinking now that it could be because of the C++ name mangling (since it worked perfect when I compiled it as a C program).

Share this post


Link to post
Share on other sites
Quote:
Original post by Sander
@Muhammad: I know that, but I had a problem a few weeks back using libglade, the XML-UI library for GTK. When I created a C++ project and tried to load glade XML files, libglade could not connect the GTK signals to my signal handlers. I'm thinking now that it could be because of the C++ name mangling (since it worked perfect when I compiled it as a C program).


Actually my first intuition would be to say that this is because of calling convention rather than name mangling. Essentially the calling convention tells the compiler how to handle the assembly commands used in passing parameters to functions and cleaning up the stack when it's done. Generally something like a signal/sink implementation would have to specifically support any desired calling conventions, and if you use the wrong one it won't work.

Share this post


Link to post
Share on other sites
Sign in to follow this