Very Computer

by **Nathan Yor** » Sun, 23 Aug 1998 04:00:00

I'm currently working on a component based application for linux.
Naturally we are using dlopen and dlsym to dynamically load new
components (aka plugins). This is our dilemma, the components are
written in C++ and dlsym is having trouble locating functions within the
libraries because C++ name mangles. If we have a shared library and a
function with prototype "void printIt(int)" we can load the library and
get a pointer to printIt if we use the symbol "printIt__fi" (the mangled
form) when we call dlsym. But further, we would also like to call the
constructor of a class using dlsym. Is this even possible, or are we on
crack? If there are any g++ or ld experts out there maybe you could
offer some insight.

If anyone has any tips or ideas on where we can go with this we sure

I suppose one could get around this by having an extern "C" block around
a C function that creates an instance of a class, but we would prefer
not to do this (for the component writers sake).

Thanks for your time and help,
Nathan York

by **Guilhem Lavau** » Mon, 24 Aug 1998 04:00:00

> I'm currently working on a component based application for linux.
> Naturally we are using dlopen and dlsym to dynamically load new
> components (aka plugins). This is our dilemma, the components are
> written in C++ and dlsym is having trouble locating functions within the
> libraries because C++ name mangles. If we have a shared library and a
> function with prototype "void printIt(int)" we can load the library and
> get a pointer to printIt if we use the symbol "printIt__fi" (the mangled
> form) when we call dlsym.

Just declare something like:
extern "C" void printIt(int);

or

extern "C" void printIt(int) { /* implementation */ }

Quote:> But further, we would also like to call the
> constructor of a class using dlsym. Is this even possible, or are we on
> crack? If there are any g++ or ld experts out there maybe you could
> offer some insight.

I don't think it's a good idea to directly call a constructor through dlsym(). First, the C++
symbols are very complicated and then it may happen strange things because of the virtual tables.
You should rather use a C function which create the object and then return the pointer to this
object: everyone do like this.

> If anyone has any tips or ideas on where we can go with this we sure

> I suppose one could get around this by having an extern "C" block around
> a C function that creates an instance of a class, but we would prefer
> not to do this (for the component writers sake).

Regards,

Guilhem.
--
----------------------------------------

|---------------------------------------
| Web: http://www.pratique.fr/~ylavaux |
----------------------------------------

by **C R Johnso** » Mon, 24 Aug 1998 04:00:00

> I'm currently working on a component based application for linux.
> Naturally we are using dlopen and dlsym to dynamically load new
> components (aka plugins). This is our dilemma, the components are
> written in C++ and dlsym is having trouble locating functions within the
> libraries because C++ name mangles. If we have a shared library and a
> function with prototype "void printIt(int)" we can load the library and
> get a pointer to printIt if we use the symbol "printIt__fi" (the mangled
> form) when we call dlsym. But further, we would also like to call the
> constructor of a class using dlsym. Is this even possible, or are we on
> crack?

Assuming your plugins are class types,

define a root class for all plugins, and a common constructor
signature

class plugin
{
plugin(whatever*);
....

Quote:};

from which derive all the specific plugin types

class myplugin: public plugin
{
myplugin(whatever*);
....

Quote:};

For each type, also define an extern"C"'d factory method
which creates instances of plugin objects:

extern "C" {
plugin* myplugin_FactoryMethod(whatever*)
{ return new myplugin(whatever*); }

Quote:}

Now you can dlsym the _FactoryMethod and create objects of the
specific plugin type.

crj

by **Nathan Yor** » Tue, 25 Aug 1998 04:00:00

Hi all,

Thanks for the insight. It looks like it will work best if we force
component writers to code this extern "C" hook into their code - trying to
mangle symbols looks to be ugly. Anyhow, thanks again.

> I'm currently working on a component based application for linux.
> Naturally we are using dlopen and dlsym to dynamically load new
> components (aka plugins). This is our dilemma, the components are
> written in C++ and dlsym is having trouble locating functions within the
> libraries because C++ name mangles. If we have a shared library and a
> function with prototype "void printIt(int)" we can load the library and
> get a pointer to printIt if we use the symbol "printIt__fi" (the mangled
> form) when we call dlsym. But further, we would also like to call the
> constructor of a class using dlsym. Is this even possible, or are we on
> crack? If there are any g++ or ld experts out there maybe you could
> offer some insight.

> If anyone has any tips or ideas on where we can go with this we sure

> I suppose one could get around this by having an extern "C" block around
> a C function that creates an instance of a class, but we would prefer
> not to do this (for the component writers sake).

> Thanks for your time and help,
> Nathan York

Nathan York

by **Dennis Pay** » Thu, 27 Aug 1998 04:00:00

Another way you could do it is to create a base plugin class that
stores all plugins in a linked list (or other structure). The plugin
designers would simply extend the plugin class and create a single
global instance of their plugin. You would know about the plugin
because the base plugin constructor would add it to the list.
(I personally don't like this option and think the extern "C" is
better.)

Dennis Payne

Very Computer

dlsym with C++ object code

dlsym with C++ object code

dlsym with C++ object code

dlsym with C++ object code

dlsym with C++ object code

dlsym with C++ object code