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 multiple times. 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! -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
