• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: RTTI and exceptions between plugins (solution)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: RTTI and exceptions between plugins (solution)
      • From: Steve Baxter <email@hidden>
References: 
 >RTTI and exceptions between plugins (solution) (From: Steve Baxter <email@hidden>)

  • Prev by Date: Re: Strip -- and hack/crack security
  • Next by Date: Re: Strip -- and hack/crack security
  • Previous by thread: Re: RTTI and exceptions between plugins (solution)
  • Next by thread: Re: RTTI and exceptions between plugins (solution)
  • Index(es):
    • Date
    • Thread