Xcode 6.x cannot link against Bitcode-enabled libMapbox.a

[incanus]

Since we landed Bitcode in ios-v2.1.1, device builds for this test project, as well as dependent projects, don't work with target build errors such as:

duplicate symbol _llvm.cmdline in:
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(SMCalloutView.o)
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(NSProcessInfo+MGLAdditions.o)
duplicate symbol _llvm.embedded.module in:
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(SMCalloutView.o)
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(NSProcessInfo+MGLAdditions.o)
duplicate symbol _llvm.cmdline in:
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(SMCalloutView.o)
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(NSString+MGLAdditions.o)
duplicate symbol _llvm.embedded.module in:
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(SMCalloutView.o)
    /Users/incanus/Documents/Projects/Mapbox/sirius-ios/Pods/Mapbox-iOS-SDK/libMapbox.a(NSString+MGLAdditions.o)
ld: 36 duplicate symbols for architecture armv7

Per @friedbunny, this might be a lead:

http://www.openradar.me/21884601

I accidentally enabled bitcode for the simulator build of my library

/cc @1ec5

[incanus]

Things are broke in Xcode 6.4 as well, since ios-v2.1.1 was generated with Xcode 7 GM.

Per the above OpenRadar link, it's not clear how you can conditionally enable Bitcode based on architecture vs. build configuration.

This might be an Xcode 7 GM issue, too.

[incanus]

Wondering if it's acceptable to release ios-v2.1.2 using Xcode 6.4, which doesn't support Bitcode and hopefully will ignore the settings. Then we can revisit this once the final, final Xcode 7 lands.

[incanus]

https://forums.developer.apple.com/thread/17529 proposes that one ship two versions of their library — one with Bitcode, one without. Which would be 4x for us, considering symbolicated / stripped as well.

[incanus]

Useful script for building device with Bitcode / sim without: realm/realm-swift#2482

[incanus]

http://codeengine.org/how-do-i-xcodebuild-a-static-library-with-bitcode-enabled/

[incanus]

I think the way forward here is to re-cast ios-v2.1.1 as ios-v2.1.2, but built with Xcode 6.4 (including Mason dependencies) so as to not trigger Bitcode — for now.

[DaveCole]

....so, will there be an XCode-7 compatible build out sometime soon?

[incanus]

Xcode 7 compatibly is in ios-v2.1.2 already, just not Bitcode support.

[1ec5]

We’ll need to compile a fat binary with Bitcode both enabled and disabled based on device versus simulator, then lipo them together. Sounds simple enough, but we may need to refactor Mason to make this possible (see mapbox/mason@41d8b2e).

/cc @springmeyer

[springmeyer]

@1ec5 - maybe we could make it possible for some environment variable to toggle bitcode in the compile/link when building with mason. Then you could - outside of mason - just the build twice and handle lipo'ing the results yourself? Or do you think "bi-fat" binaries are something mason should enable out of the box?

[1ec5]

Mason already enables Bitcode for device architectures and disables it for simulator architectures before lipoing the results together. That’s why @incanus is only seeing these errors when building for a device in Xcode 6.4.

[1ec5]

So far I’ve been looking at producing a fat binary that has Bitcode enabled or disabled all the way down to Mason, but the main holdup has been explicitly disabling Bitcode in the gyp-generated projects when built in Xcode 7 – the ENABLE_BITCODE setting doesn’t seem to make it through to the project when specified in the .gypis.

We’re now looking at a simpler route, which is to distribute two completely separate builds, one built in Xcode 7 (with Bitcode) and one built in Xcode 6.4 (without). The Bitcode-less build will be installable as an optional CocoaPod subspec. I still need to work out how this will impact our release tooling.

[1ec5]

My current thinking is that we’d run an additional publish build that strips the binary of Bitcode markers after the fact:

xcrun bitcode_strip -r build/ios/pkg/static/libMapbox.a -o build/ios/pkg/static/libMapbox_bitdecode.a

It works well, but I do get plenty of warnings along these lines:

warning: (arm64) /tmp/bitcode_strip.w3ZmpZ unable to open object file: No such file or directory