Re: RTTI and exceptions between plugins (solution)
Re: RTTI and exceptions between plugins (solution)
- Subject: Re: RTTI and exceptions between plugins (solution)
- From: Steve Baxter <email@hidden>
- Date: Wed, 8 Feb 2006 18:45:03 +0000
Hi Thomas,
You only need to use RTLD_GLOBAL if you want RTTI and exceptions to
work across the plugins. In your case you should be OK with the
current behaviour - by default symbols in loaded dylibs are private.
Cheers,
Steve.
On 8 Feb 2006, at 10:03, Thomas Engelmeier wrote:
- 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:
40improvision.com
This email sent to email@hidden
Stephen Baxter
Software Development Manager
Improvision
email@hidden
+44-2476-692229
_______________________________________________
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