iOS App with Static Lib Always Crashes on Launch of Ad Hoc Archive Build. Cant Reproduce in Xcode Debugger

iOS App with Static Lib ALWAYS crashes on Launch of Ad Hoc Archive Build. Cant reproduce in Xcode Debugger

Figured it out!! after 4 days of banging heads on desk. We don't know exactly why it works but it does. In case it's helpful to others here are the settings that resolved it for us. Set these in the "Deployment" section of the Static Library Project's Build Settings:

SET "STRIP LINKED PRODUCT" (STRIP_INSTALLED_PRODUCT) = NO
SET "STRIP STYLE" = DEBUGGING SYMBOLS.

We found this by trial and error but now notice that a few discussions online re setting up an Xcode project for building iOS static libraries use this setting. No discussion as to why, but there it is.

If anyone has any thoughts on why these lib settings fix it you might want to comment on it here.

iOS App with Static Lib crashes ONLY on launch of Archive Build loaded Ad Hoc. Can't reproduce in Debugger

I'll repost and expand upon my comment from above so that this question can have an accepted answer.

I recently came across a case similar to this when building my GPUImage framework. It appears that the build process is slightly different when archiving than when building and directly installing an application on the device via Xcode.

This can be exposed by building and archiving the application, then choosing to distribute it for ad hoc or enterprise distribution. Take the .ipa and place it in iTunes and manually load it on one of your test devices that way. The behavior of an application prepared in this manner may differ from one built and installed through Xcode, and should be closer to how a build submitted for review will act.

In my case, the problem was due to a lack of proper weak linking. On SDKs newer than iOS 4.3, you should no longer need to weak link whole frameworks if you wish to conditionally use classes and functions that are present in newer SDKs but missing in older ones. If you target 4.0 and higher, the linker should now perform class- and function-level weak linking.

However, this was failing for people using my static library, which does runtime checks for the presence of the new texture cache functions in iOS 5.0, but it only failed in these archived builds. I never saw it in all my testing against 4.x devices, because that was done by installing via Xcode. In the end, I needed to have users explicitly weak link the entire Core Video framework in order to get applications using this framework to run properly when archived and installed via iTunes.

Note that this wasn't due to the Release vs. Debug build configurations, because I tried switching between these in my build schemes when deploying to the device through Xcode and it made no difference there. Something else is different in the way that archived applications are built and linked.

Is there a better way to link to a configuration specific static lib on iOS than OTHER_LINKER_FLAGS?

So, it turns out I was letting the Xcode UI confuse me. If you add the generic search path with the ${CONFIGURATION} variables and then add one of the static library instances to the project and target it'll do the right thing and link with the right one even though if you get info on that library in the project it'll show you the specific path.

However, if you want it to actually have Xcode notice changes made to one of the static libraries, you'll need to add ALL versions of your static library to the project and target (yes, it'll look like it's linking with all three, no worries!).

To have Xcode detect the the .a file changed as the result of a build script phase you have to actually have all the source files that are used to build the .a file in the Run Script Input pane (a pain!) to not have to run your build script every time; And all three variants of the .a file in the output pane so Xcode knows what to check after your script runs to see if it needs to relink the project.

iOS project wants me to Upgrade assembler codgen and debugger

LLDB has its advantages but IMHO is not as stable as GDB is. In most cases LLDB is fine and will work properly. When something weird happens while debugging, simply switch back to GDB within the Scheme settings. So accepting this Upgrade is just fine.

Creating ARM instead of THUMB code on ARMV6 basically is a workaround for a bad bug in LLVM (the objective-c compiler Apple now prefers). If you would not accept this change, chances are pretty high that ARMV6 targeted code will be falsely optimized, rendering issues into your App you would not have expected. To spell it out clear, the ARMV6 Thumb optimizing is buggy in LLVM 3.1 (as bundled with Xcode 4.3.2 and lower). So accepting this Upgrade is IMHO mandatory.

---

Related Topics