Shared libraries / C++

[jon.apostoles]

I have a program that is going to have plugins used for various
capabilities. The main program creates a class (AppCore) which handles
everything. This class contains another class (PluginController) that
handles loading the shared objects via the dl* functions. When I
create the plugins, I link them using -shared.

The plugins themselves are derived from a class (Plugin)... inside of
the Plugin class there is a variable to hold a pointer back to the
AppCore object. This is so the plugins can call various functions from
AppCore object created at start up.

Should I have to link in the AppCore.o the plugins when I'm creating
them? It seems like it wont work unless I do that.. I'm not sure I
understand why I need to link those in.. shouldn't the main program
export those symbols?

 

[Rolf Magnus]

I have a program that is going to have plugins used for various
capabilities. The main program creates a class (AppCore) which handles
everything. This class contains another class (PluginController) that
handles loading the shared objects via the dl* functions. When I
create the plugins, I link them using -shared.

The plugins themselves are derived from a class (Plugin)... inside of
the Plugin class there is a variable to hold a pointer back to the
AppCore object. This is so the plugins can call various functions from
AppCore object created at start up. Should I have to link in the AppCore.o
the plugins when I'm creating them? It seems like it wont work unless I
do that.. I'm not sure I understand why I need to link those in..
shouldn't the main program export those symbols?

No. At least under Linux, the plug-in doesn't have access to any symbols of
the main program. The usual solution to that is to write a shared library
that contains everything that both the main program and the plug-in need,
and then link them both to that library.

 

[SnaiL]

No, you don't need to link plugin DLL (SO) files with AppCode.
Moreone, you should not do that

 

[Shezan Baig]

I have a program that is going to have plugins used for various
capabilities. The main program creates a class (AppCore) which handles
everything. This class contains another class (PluginController) that
handles loading the shared objects via the dl* functions. When I
create the plugins, I link them using -shared.

The plugins themselves are derived from a class (Plugin)... inside of
the Plugin class there is a variable to hold a pointer back to the
AppCore object. This is so the plugins can call various functions from
AppCore object created at start up.

Should I have to link in the AppCore.o the plugins when I'm creating
them? It seems like it wont work unless I do that.. I'm not sure I
understand why I need to link those in.. shouldn't the main program
export those symbols?

The problem with this is that it introduces cyclic dependencies (bad
thing). i.e., AppCore depends on PluginController, and
PluginController depends on AppCore (to pass the pointer to the plugins
when loaded). You will have something like this:

,---------. ,------------------.
| |------->| |
| AppCore | | PluginController |
| |<-------| |
`---------' `------------------'

One solution is to have a pure virtual interface (e.g., AppInterface),
that provides all the methods that plugins would need to call in the
applications. Have AppCore implement this interface and just pass the
pointer to AppInterface. That way, your dependency diagram looks like
this:

,---------. ,--------------. ,------------------.
| AppCore |---->| AppInterface |<----| PluginController |
`---------' `--------------' `------------------'

Your linker will thank you for it

Hope this helps,
-shez-

 

[jon.apostoles]

Thanks a ton! That's exactly what I was looking for. I implemented it
using an API class that is included by the core, and the plugins.
Cyclic dependencies are now gone, and it links the way I want it.

Thank you very much )