My app supports external plugins. On macOS, Linux, and Windows those plugins
are just shared objects/dylibs (or DLLs) loaded via dlopen() (or LoadLibrary()
on Windows) at runtime.
Every plugin needs to export a fixed set of symbols which are then resolved at
runtime, e.g. symbols named InitPlugin(), FreePlugin(), and so on.
Now I'm looking for a way to port this design to iOS. The obvious choice seems
to be turning the individual plugins into individual Cocoa Touch Frameworks.
However, this results in the following big problem: The symbol names are the
same for every plugin, i.e. every plugin has a symbol named InitPlugin(), a
symbol named FreePlugin(), and so on.
Managing this isn't a problem when manually opening shared objects/dylibs
using dlopen() but it is a problem when iOS automatically imports all symbols
at app startup because then there are clashes because symbols are defined
Is there any convenient way to migrate my original, dlopen()-based design
to Cocoa Touch Frameworks or do I have to do it the hard way and make sure
symbol names are unique? For example, I could go ahead and simply prefix all
symbol names like InitPlugin(), FreePlugin() with identifiers unique to each
plugin and then include a mapping table for each plugin in my main app.
It's not that much of a big deal but still it means extra work so I'd first
like to hear whether there is any way of imitating my original dlopen() approach
with Cocoa Touch Frameworks.
Thanks for suggestions!
Andreas Falkenhahn mailto:andr...@falkenhahn.com
Cocoa-dev mailing list (Cocoafirstname.lastname@example.org)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to arch...@mail-archive.com