removing Z9[function_name]_ from shared library symbols
Author
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.
Author
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!
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!
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.
Rule of thumb: if you're going to dlopen() a library and dlsym(), you want to use C linkage.
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?
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.
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
}
@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).
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
