On Mon, Mar 29, 2010 at 12:18 AM, Manohar Vanga <[email protected]>wrote:
> Actually if the header file is simply included (which it was), name > mangling is not a problem. The function missing was called subscribe(). Here > are the tests: > > $ nm server | grep subscribe > 0804f090 T _ZN5Server6Module16subscribeEjj > > The above is the mangled name within the server binary (the function lies > in the Server::Module namespace). The "T" indicates that it is in the text > segment of the binary. > > Now, when I compile the module with the header file for the server > included: > > $ nm Modules/testmodule.so | grep subscribe > U _ZN5Server6Module16subscribeEjj > > The "U" here means this symbol is undefined. Note that the compiler > generated the mangled name correctly as in the server. The issue of name > mangling only makes a difference when different compilers are used for > modules and the main loader. Note that even extern "C" is not needed unless > compiling the two parts with different compilers. The reason for using them > is to have consistency across all compilers (I don't really care about this > as modules are part of the source and I will compile them together with the > main loader using one compiler). > I thought you wanted it to be loadable using dlopen. If you link it this way, main app will have dependency on the so file and therefore would require it while running the main app itself. If you want it to be like a loadable plugin, you would have to follow the approach I mentioned in my previous mail. Main app should never link with the plugin. Otherwise the whole concept of "plug-in" is useless, as you won't be able to plug-out. Even if you use multiple compilers, name mangling issue won't come up if the compilers have object file compatibility. Anyway, you don't seem to have that as a requirement, so that's fine. > > Even though the names were the same, there was an "undefined symbol" error > being thrown up. The issue was simpler than I thought. Being used to C, I > didn't know this from experience. Solution? Add the "-export-dynamic" flag > when linking the main loader and module. > > Thanks for all the help :-) > Manohar > > > On Sun, Mar 28, 2010 at 7:36 PM, coderbean <[email protected]> wrote: > >> Please note that extern "C" only works for global functions. It is >> mentioned in the link below, but I just wanted to stress that. >> >> On Mar 28, 2010, at 10:14 AM, suman karthik wrote: >> >> from http://linux.math.tifr.res.in/HOWTO-text/C++-dlopen >> >> 2. The Problem >> >> At some time you might have to load a library (and use its functions) at >> >> runtime; this happens most often when you are writing some kind of plug-in or >> module architecture for your program. >> >> In the C language, loading a library is very simple (calling dlopen, dlsym >> and dlclose is enough), with C++ this is a bit more complicated. The >> >> >> >> difficulties of loading a C++ library dynamically are partially due to name >> mangling, and partially due to the fact that the dlopen API was written with >> C in mind, thus not offering a suitable way to load classes. >> >> >> >> Before explaining how to load libraries in C++, let's better analyze the >> problem by looking at name mangling in more detail. I recommend you read the >> explanation of name mangling, even if you're not interested in it because it >> >> >> >> will help you understanding why problems occur and how to solve them. >> ----------------------------------------------------------------------------- >> >> 2.1. Name Mangling >> >> In every C++ program (or library, or object file), all non-static functions >> >> >> >> are represented in the binary file as symbols. These symbols are special text >> strings that uniquely identify a function in the program, library, or object >> file. >> >> In C, the symbol name is the same as the function name: the symbol of strcpy >> >> >> >> will be strcpy, and so on. This is possible because in C no two non-static >> functions can have the same name. >> >> Because C++ allows overloading (different functions with the same name but >> different arguments) and has many features C does not ?? like classes, member >> >> >> >> functions, exception specifications ?? it is not possible to simply use the >> function name as the symbol name. To solve that, C++ uses so-called name >> mangling, which transforms the function name and all the necessary >> >> >> >> information (like the number and size of the arguments) into some >> weird-looking string which only the compiler knows about. The mangled name of >> foo might look like f...@4%6^, for example. Or it might not even contain the >> >> >> >> word "foo". >> >> One of the problems with name mangling is that the C++ standard (currently [ >> ISO14882]) does not define how names have to be mangled; thus every compiler >> mangles names in its own way. Some compilers even change their name mangling >> >> >> >> algorithm between different versions (notably g++ 2.x and 3.x). Even if you >> worked out how your particular compiler mangles names (and would thus be able >> to load functions via dlsym), this would most probably work with your >> >> >> >> compiler only, and might already be broken with the next version. >> ----------------------------------------------------------------------------- >> >> 2.2. Classes >> >> Another problem with the dlopen API is the fact that it only supports loading >> >> >> >> functions. But in C++ a library often exposes a class which you would like to >> use in your program. Obviously, to use that class you need to create an >> instance of it, but that cannot be easily done. >> ----------------------------------------------------------------------------- >> >> >> >> 3. The Solution >> >> 3.1. extern "C" >> >> C++ has a special keyword to declare a function with C bindings: extern "C". >> A function declared as extern "C" uses the function name as symbol name, just >> >> >> >> as a C function. For that reason, only non-member functions can be declared >> as extern "C", and they cannot be overloaded. >> >> Although there are severe limitations, extern "C" functions are very useful >> >> >> >> because they can be dynamically loaded using dlopen just like a C function. >> >> This does not mean that functions qualified as extern "C" cannot contain C++ >> code. Such a function is a full-featured C++ function which can use C++ >> >> >> >> features and take any type of argument. >> >> please find example source and more info at the link provided above. >> >> >> On Sun, Mar 28, 2010 at 5:53 AM, Manohar Vanga >> <[email protected]>wrote: >> >>> Hi, >>> >>> I have a main program that is loading up modules dynamically at run time. >>> Suppose I have a function "foo" in the namespace "Module" (Module::Foo) >>> within the main program. I need a way to access it from a dynamically loaded >>> module. If I link with the source file containing the namespaces, it will >>> create duplicate copies and when some variable is accessed, it will be the >>> duplicate and not the one from the main program. >>> >>> If I declare the function as extern in the module, the module compiles >>> fine but dlopen() complains that foo() is missing and fails. Any suggestions >>> as to how I can accomplish this? >>> >>> Thanks >>> Manohar >>> >> >> >> >> -- >> -Suman >> http://www.sumankarthik.com >> >> >> >
