Hello,
<sorry for resposting, I accidentally removed some text from the email>
Being aware that Apple doesn't allow apps with dynamic libraries (except for those provided by them), I'm trying to make Gambit's dynamically loadable libraries work in the platform.
I can make them work well on the iOS simulator, but on the iPhone/iPad devices don't work. The funny thing is that as soon as the (load) procedure is called...
- When running with Xcode connection, the app stalls with no output or crash at all. - When running directly on the device without Xcode debugging connection, then it crashes.
All compiler and linker flags have been checked thoroughly. Compiling and linking work flawlessly, and the load procedure doesn't throw any error.
Is this an expected behavior? Any ideas of why this behavior might occur?
Best regards,
Álvaro
Afficher les réponses par date
We encountered this problem years ago in the early development of LambdaNative. The first versions used dynamically loadable modules, which turned out to be problematic on several platforms. If memory serves me we did have Gambit’s dynamic loading working on jailbroken iOS devices at one point. I don’t think Apple makes any distinction between dynamic libraries and Gambit's loadable libraries though, and apps using it are probably going to be rejected on the store anyway.
Chris
On Jul 3, 2014, at 4:05 PM, Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.commailto:alvaro.castro.castilla@gmail.com> wrote:
Hello,
<sorry for resposting, I accidentally removed some text from the email>
Being aware that Apple doesn't allow apps with dynamic libraries (except for those provided by them), I'm trying to make Gambit's dynamically loadable libraries work in the platform.
I can make them work well on the iOS simulator, but on the iPhone/iPad devices don't work. The funny thing is that as soon as the (load) procedure is called...
- When running with Xcode connection, the app stalls with no output or crash at all. - When running directly on the device without Xcode debugging connection, then it crashes.
All compiler and linker flags have been checked thoroughly. Compiling and linking work flawlessly, and the load procedure doesn't throw any error.
Is this an expected behavior? Any ideas of why this behavior might occur?
Best regards,
Álvaro _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.camailto:Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Jul 3, 2014, at 7:05 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Hello,
<sorry for resposting, I accidentally removed some text from the email>
Being aware that Apple doesn't allow apps with dynamic libraries (except for those provided by them), I'm trying to make Gambit's dynamically loadable libraries work in the platform.
I can make them work well on the iOS simulator, but on the iPhone/iPad devices don't work. The funny thing is that as soon as the (load) procedure is called...
- When running with Xcode connection, the app stalls with no output or crash at all.
- When running directly on the device without Xcode debugging connection, then it crashes.
All compiler and linker flags have been checked thoroughly. Compiling and linking work flawlessly, and the load procedure doesn't throw any error.
Is this an expected behavior? Any ideas of why this behavior might occur?
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
On Fri, Jul 4, 2014 at 5:37 AM, Marc Feeley feeley@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