<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 4, 2014 at 5:37 AM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">I think that is a constraint of the iOS (no dynamic loading of shared libs).<br>

</div>
<br>
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.<br>


<span class=""><font color="#888888"><br>
Marc<br>
<br>
</font></span></blockquote></div><br><br>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.<br>One possibility is that codesigning the loadable object is mandatory (this post dives into some details of dylib: <a href="http://realmacsoftware.com/blog/dynamic-linking">http://realmacsoftware.com/blog/dynamic-linking</a>).<br>

<br>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).<br><br>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.<br>

<br><br>Álvaro<br><br></div></div>