Binding to iOS static library that does not support x86_64, trying to load into newer simulator

Josh.1093Josh.1093 USUniversity ✭✭

I have a native iOS static library built a few years ago by a vendor to support their hardware add-on. Past versions of the library included slices for both i386 and x86_64 that did not do anything, but if they aren't called, don't hurt anything. That would let me load an app that uses the resulting iOS binding library on both real devices, and in the simulator. On the simulator, my app would conditionally not use their SDK, and things would be fine.

The vendor dropped the x86_64 slice from their static library in their latest version. As a result, when I try to build an app using the new binding library, native symbols are missing. I am not likely to get the vendor to update their library to add back x86_64 in a reasonable amount of time.

Can anyone sketch out a way that I could build a binding library that would resolve native symbols if present in an architecture, and stub them out if missing? Since the binding library is built for multiple architectures, I can't think of a compile-time approach. I would need a way for the consumer of the binding library to have stubs of the APIs exposed by binding to ARM.

Posts

  • Josh.1093Josh.1093 USUniversity ✭✭
    edited March 2018

    My crude solution, given that I have a header file for the static library, is to implement my own static library project, add the header, implement it as a pure stub, and then use "lipo" to add my x86_64 slice to the original vendor supplied static library. I can then load the resulting library into the simulator. Hopefully the resulting static library still works on the device. It should, as it still has those slices. If it builds, and it does, it should work!

    See native-interop for lipo usage.

    If anyone can think of anything less labor intensive, or more elegant, I'm all ears! Stubbing out the API is a pain in the neck, but not insurmountable.

Sign In or Register to comment.