dynamically loaded libraries

[go939]

hey there!

i would like to ask help on how to use the dlsym() in making a dll test program. can somebody gave me a sort of reference for me to study?

THANKS

[Duoas]

Google is your friend.

Try this.

Good luck.

[go939]

yup. thanks. but i have a problem. how can i use the dlsym() to open a class name and its functions?

[Duoas]

You can't. DLLs only export functions, not classes.

[vijayan121]

> DLLs only export functions, not classes
dlls export addresses of symbols. the symbols may be of anything which has external linkage. eg.

int symbol_one(double) { /* ... */ }
int symbol_two = 67 ;
class X
{
  int symbol_three(double) ;
  static int symbol_four ;
}; 
int X::symbol_three(double) { /* ... */ }
int X::symbol_four = 67 ;

symbol_one, symbol_two, X::symbol_three, X::symbol_four would all be exported.
note: in windows, the export is selective; so you would also require a __declspec(dllexport)

> how can i use the dlsym() to open a class name and its functions?
the real issue is symbols in c++ are decorated (mangled) with embeded type and namespace information. for free functions/variables at global scope, we could simply use an extern "C" to get rid of the decoration. for symbols in namespaces/classes, one option would be to create a 'map' in the shared library that maps user-specified names to symbol addresses. another would be to use the name mangling/unmangling routines from libiberty.

a more flexible approach would be to use virtual functions along with an extern "C" factory method. for example

struct A // common to .so and user program
{
  virtual int symbol_one(double) = 0 ;
  virtual ~A() {}
  // etc
};

struct A_imp : A // to be exported
{
  virtual int symbol_one(double) ;
  // etc
};

extern "C" A* create_A() { return new A_imp ; }

this avoids the name problem for member functions altogether; they are bound at run-time through a vtbl lookup.

[Duoas]

I understand DLLs just fine. I've written code to handle import and export tables. That's not what the OP wants.

No PE exports types. Remember, a class is a data type, not an addressable object.

Using data objects from a foreign DLL is always a tricky thing because you must know its exact memory footprint to play with it. For simple things like integers and doubles that isn't a problem, but when you start playing with C++ classes life becomes triply hard. You are better off compiling and linking the code yourself.

If you are sure you are using the exact same compiler system and exact same version as the one that compiled the DLL you want to use, you can probably get away with simply including the class header and linking the methods in the DLL.

Either way, it is a lot of work, and based solely upon the OP's original questions I expect he knows next to nothing about DLLs and their inner workings.

Driving a car is one thing. Knowing the tolerances in the gas manifold is another.