By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,189 Members | 902 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,189 IT Pros & Developers. It's quick & easy.

Shared libraries / C++

P: n/a
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?

Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
jo***********@gmail.com wrote:
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.

Jul 23 '05 #2

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

Jul 23 '05 #3

P: n/a

jo***********@gmail.com wrote:
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-

Jul 23 '05 #4

P: n/a
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 :o)

Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.