build a single .a for simulator and device containing arm64 (targeting M1 simulator too) possible?

Question

We are facing problems with lipo/libtool when trying to build a fat static lib for simulator and device. Before M1 arm64 all went fine with an armv7/arm64 slices for the device and an x86_64 slice for the simulator. Now lipo can't spot the difference between the arm64 build for simulator and the arm64 build for the device and refuses to add 2 arm64 slices.

1. Is there a way to build a 'generic' arm64 lib slice (because the code in our lib is platform agnostic)

2. Are there other tools to achieve packing 2 arm64 slices into a .a or do we need to build now 2 separate static libs for simulator and device ? (Please note we do not use Xcode for building, so we are just linking on the command line).

3. Interestingly when linking against dynamic standard libs such as libxml a -lxml is sufficient regardless of the platform however this is for dynamic libs, not static. Does a similar mechanism exist for static libs ?

Linkboy

You need migrate lib to xcframework – Hartzel

@Hartzel can an XCFramework be used in a clang link command line ? (again: we use neither Xcode nor xcodebuild). if I do a "man clang" there is no mention of xcframework options (which isn't a bullet proof argument against it because also an option like "-target" isn't really documented in the clang man page). – Linkboy

Answer 1

We ended up in creating 2 separate versions of all our static libs: one containing the arm64 code for the device and one containing both the x86_64 and arm64 slices for the simulator. The command line trick to create both simulator slices for an object in one rush when compiling with clang is

clang -target x86-apple-ios-simulator -target arm64-apple-ios-simulator -arch x86_64 -arch arm64 ...

When linking we have separate suffixes, for ex libFOO_S.a for the simulator lib and pick the suitable depending on if building for the simulator or not. I didn't find a way to have all slices for device/simulator in one fat .a ... it's simply not foreseen.

Linkboy