[gambit-list] Dynamically loadable libraries on iOS

Álvaro Castro-Castilla alvaro.castro.castilla at gmail.com
Fri Jul 4 05:52:44 EDT 2014


On Fri, Jul 4, 2014 at 5:37 AM, Marc Feeley <feeley at iro.umontreal.ca> wrote:


> I think that is a constraint of the iOS (no dynamic loading of shared
> libs).
>
> Is dynamic loading of shared libs really required by your application?
>  There is an alternative which gets similar effect… you bundle all the
> modules in a single executable file but only “preload” those that are
> required initially and “load” the rest on demand.  This can be done with
> the -nopreload compiler switch and the ##load-required-module function.
>
> Marc
>
>

Thanks for your replies. I was puzzled by this behavior, because it doesn't
look like an error/segfault, but more of a kernel protection.
One possibility is that codesigning the loadable object is mandatory (this
post dives into some details of dylib:
http://realmacsoftware.com/blog/dynamic-linking).

Yes, Apple wouldn't allow loading code in any case for security reasons. We
have to be thankful that they allow generating C code from an alien
language (any that is not C/ObjC/Swift).

Actually, my intention was to provide this functionality for the
development process, so it's already doing its job working on i386/x86_64
architectures in the simulator. I didn't find any use case where I totally
need loadable libraries in production code. However, that trick is totally
neat and may be very useful. For instance, it could be useful if you have
different versions of an app that are chosen at runtime so you couldn't use
a fat lib.


Álvaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20140704/f7e98352/attachment.htm>


More information about the Gambit-list mailing list