Re: RTTI and exceptions between plugins (solution)
Re: RTTI and exceptions between plugins (solution)
- Subject: Re: RTTI and exceptions between plugins (solution)
- From: Thomas Engelmeier <email@hidden>
- Date: Wed, 8 Feb 2006 11:03:26 +0100
- You must load your plugins using dlopen() with RTLD_GLOBAL
This causes the symbols in each plugin to be added to the
application's symbol table as the plugin is loaded. As further
plugins are loaded, their symbols will be resolved against the
symbols in the already running application, and the one definition
rule will be obeyed. If plugin A has symbol X, when plugin B loads
that also has symbol X, it will link against plugin A's copy, not
its own.
Now for the problem. It is easy to export all the symbols in your
plugin - this is the default behaviour in Xcode. If however you
load your plugin using CFBundle, it will do the wrong thing.
CFBundle loads the plugin (dylib) with private (local) symbols.
From CFBundle.c:
Well, this is for me an huge show stopper.
The complete idea of a plug-in architecture is to separate symbol
spaces. Under absolutely no circumstances the plain existence of
plugin A shall influence the code executed of plugin B - the only
property they may share is an entry-point / interface object. OK, so
no polymorphism for objects coming from plug-ins.
Just as an basic example, think of two independent Quark XTensions /
Indesign Plugins from two vendors. Both use a "private" static
instance of libTiff and have taken the additional measure to prevent
Apple ld's automatic replacement with the system dylib version. In
one of the binaries libTiff is fixed for CMYK handling, the other has
fixes for bitone support.
Just depending on the load order there would be the wrong version
called.
The standard C++ workaround would be to bring each and every class
for a given plugin in its own namespace, unfortunately using
namespaces brings the usuability of XCode down to an GUI-variant of vi.
Regards,
Tom"In the middle of porting a huge plugin based project with exacly
such an "problematic" architecture"E
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden