ctypes_patch introspection fails on iOS apps packaged for distribution about rubicon-objc HOT 11 CLOSED

You can get this working for distribution by modifying the project settings to disable stripping and/or bitcode. Go to the build settings and set the following for the release builds:

     "Strip Debug Symbols During Copy" = NO 
     "Strip Linked Product" = NO 
     "Strip Style" = Debugging Symbols 
     "Enable Bitcode" = NO 

I also encountered this issue and the above fixed it.

The disabling of Bitcode isn't the end of the world -- your apps generally will run ok without it. It's only for future-proofing with future versions of iOS and processor arch's.

from rubicon-objc.

If you comment out the import of the ctypes_patch module (line 13 of runtime.py) the app works; so it's just a problem with introspecting the Python library.

from rubicon-objc.

Hm, I'm guessing that something in the build process for distribution is stripping the PyType_stgdict symbol out. Can you run nm -a on the distribution build's Python binary and upload the output as a Gist or something? I'd be interested in seeing whether the distribution binary has any useful symbols at all.

from rubicon-objc.

Unfortunately not (or, at least, I'm not sure how I'd do it). The problem only manifests in an Ad Hoc or Distribution build, at which point you've only got an IPA, not a library you can usefully introspect. I'll poke around and see if I can find any way to pull apart an IPA to see what's inside...

from rubicon-objc.

IPAs are just ZIP archives as far as I know, so you can change the extension or drop them onto Archive Utility to extract them. Inside is a normal iOS .app bundle, you can "Show Package Contents" on it and the binaries should be inside.

from rubicon-objc.

Oh - I didn't realise IPA files were just ZIP archives... Here's an NM dump for an nm dump of an Ad Hoc build (which crashes), and a development build in release mode (which doesn't).

https://gist.github.com/freakboy3742/49fc0a92921bd0bc3f1bc3c940ca4aea

You're right - it looks like all the unused symbols are being stripped. I wonder if just instantiating an instance of PyType_stgdict in the mainline (not actually using it - just instantiating it in C so that the symbol exists) will do the job...

from rubicon-objc.

Actually I think all symbol exports are being stripped, except for __mh_execute_header, the main entry point. All the other symbols in the nm list are imports from system libraries. I'm guessing this is just an optimization - since this is the main application binary, nothing other than the binary itself ever needs its symbols, so they can be stripped (and all internal uses can be replaced with static addresses). Of course this is an issue when we want to look up symbols in the application binary at runtime...

One possible solution would be to not compile/statically link Python into the main binary, but instead make it a separate dynamic library or framework. This is how it's done in Pythonista - there is a Py3Kit.framework that contains the Python runtime, and looking up symbols in ctypes.pythonapi works fine in Pythonista.

(PS: Looks like the nm list is duplicated, because the distribution binary is built for 32/64-bit. You can pass -arch arm64 so it won't display the redundant 32-bit symbols.)

from rubicon-objc.

I seem to recall that dynamic libraries were a problem on older iOS versions, which is why the current BeeWare builds are all static linked. However, if that requirement has been relaxed, dynamic libs might be a better approach...

from rubicon-objc.

Following up on this - making the changes referred to by @cculianu didn't fix the problem for me, but after some more fiddling with xcode build settings, it appears that the "Enable Testability" =YES setting does. This is set to "NO" for release by default.

I have no idea why this works, but I've found a couple of references that suggest that it might be related to having a static library compiled with -fvisibility=hidden.

from rubicon-objc.

Good to know.. thanks for the update. It's always a struggle getting this stuff to work right as Apple changes things..

from rubicon-objc.

I'm going to close this; it looks as if the current Rubicon, combined with the "enable testability" change in Xcode (which has been added into the Briefcase iOS template) resolves this issue.

from rubicon-objc.