Bitcode not embedded in iOS framework binaries

[ChristianSteffens]

Hello,

I'm using the latest release v0.95.2. The release notes states that bitcode is enabled, but in the corresponding sources bitcode isn't enabled for all targets / schemes. Could this be a problem?

In my Xcode Project (bitcode is enabled) I get this error:

/Applications/Xcode.app/Contents/Developer/Toolchains/
 XcodeDefault.xctoolchain/usr/bin/bitcode_strip: 
bitcode segment can't have symbols defined it its sections in:   
/Users/hibento/Repositories/myProject/Carthage/
 Build/iOS/myFramework.framework/Frameworks/Realm.framework/Realm (for architecture arm64)
error: bitcode_strip  /Users/hibento/Repositories/myProject/Carthage/Build/iOS/
 myFramework.framework/Frameworks/Realm.framework/Realm:       
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
 /usr/bin/bitcode_strip exited with 1

[jpsim]

Thanks for reporting this. You're right that not all platforms that we say have bitcode embedded currently do, despite our recent efforts to do so (see #2567 and #2575 among several others).

Running otool -l core/librealm-*.a | grep LLVM fails for all core libraries other than watchOS. From our 0.95.2 release zips, our watchOS binaries for Realm Objective-C and Realm Swift are the only ones that contain bitcode according to the above test.

[ChristianSteffens]

Are there any news regarding this issue? Could I provide you with more information? Currently we're unable to build / run Realm on our project and device.

[tgoyne]

This should have no impact on your ability to run your project locally. Bitcode is only relevant for submitting to the app store.

[ChristianSteffens]

Okay, that´s true - but in our project with using 4 other frameworks, all of them with bitcode support. Correct if I'm wrong: But you either activate bitcode for all frameworks in your project or not at all. So to be able to build our project we have to change the settings for the remaining 4 frameworks.

I would do this gladly, but since we're using some prebuilt frameworks that´s not an option.

[jpsim]

So to be able to build our project we have to change the settings for the remaining 4 frameworks.

That shouldn't be necessary for building & running, only when archiving.

[ChristianSteffens]

So to be able to build our project we have to change the settings for the remaining 4 frameworks.

That shouldn't be necessary for building & running, only when archiving.

I thought that myself, but apparently not (see error above). I can build and run our project without any problems in the simulator, but running one a real device fails. I'll keep looking, maybe there´s something wrong with my project settings.

[tgoyne]

It appears that we need to be building the simulator version with -fembed-bitcode-marker, as otool only lists bitcode sections if all slices at least have the marker.

[jpsim]

It looks like Xcode 6.4 can't properly parse static libraries with bitcode, instead detecting duplicate symbols contained within the bitcode segment. This means that we'll need to update our core, objc and swift releases to contain copies of the iOS libraries both with and without bitcode. Thanks Apple!

[ChristianSteffens]

After updating to Realm version 0.92.3 carthage throws an error:

 Failed to write to /Users/hibento/myProject/Carthage/Build/iOS: 
 Error Domain=NSCocoaErrorDomain Code=516 
 "The file “iOS” couldn’t be saved in the folder “Build” because a file with the same name already exists." 
 UserInfo={NSFilePath=/Users/hibento/myProject/Carthage/Build/iOS, 
 NSUnderlyingError=0x7fceb9c7f7b0 {Error Domain=NSPOSIXErrorDomain Code=17 "File exists"}}

With version 0.92.2 everything works fine. I deleted the carthage Checkout folder and Cache - still the same error. Is there a problem with the shared building scheme?

[tgoyne]

Are you using Carthage 0.9.2? Homebrew only has 0.8.0, which has some bugs related to installation that effect us.

[ChristianSteffens]

That's right - with the current Carthage version it´s building and the new release solves the bitcode problem, thanks a lot!

[jpsim]

This is fixed as of yesterday's 0.95.3 release: https://github.com/realm/realm-cocoa/releases/tag/v0.95.3

[tomekc]

Hi, I'm having sense it did not improve yet...
I just upgraded my project to Swift 2.0, bumped Realm to newest 0.95.3 (using CocoaPods), and getting this error:

ld: '/Users/tomek/Devel/Mobile/BackOffice/Pods/Realm/core/librealm-ios.a(bptree-iPhoneOS-no-bitcode.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

otool -l librealm-ios.a | grep LLVM yields nothing.

[karapigeon]

@tomekc: I would recommend cleaning your project + deleting the derived data. If you're still having problems, remove the Pods directory and run pod install again.

[jpsim]

In order for us to continue supporting Xcode 6 alongside Xcode 7, it is necessary to provide both bitcode and non-bitcode versions of our core libraries.

With CocoaPods, a symlink is created when downloading the core binaries linking librealm-ios.a to the appropriate bitcode/non-bitcode version depending on which Xcode is xcode-selected.

If you remove the Pods directory, set xcode-select to point to Xcode 7, and run pod install again, this should resolve itself.

[gabro]

Worth noting that CocoaPods must be at least v0.96.
That's what was causing the error on my machine.

[tomekc]

Thanks for great tip - I almost forgot about xcode-select, indeed still pointing to Xcode 6 installation.

[jpsim]

We actually require CocoaPods 0.39.0.

[kurko]

@jpsim thanks for the tip. There's something wrong here though. Check this out:

$ xcode-select -print-path
/Applications/Xcode7.app/Contents/Developer/
$ pod --version
0.39.0
$ rm -rf Pods/
$ pod install
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
Installing Realm (0.96.1)
Installing RealmSwift (0.96.1)
# ... other dependencies
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There are 3 dependencies from the Podfile and 7 total pods installed.

Then, 1) open project in Xcode7, 2) Cmd+shift+K, 3) Build for my mobile device (not simulator), results in:

ld: '/Users/kurko/www/ios/MyApp/Pods/Realm/core/librealm-ios.a(bptree-iPhoneOS-no-bitcode.o)' 
does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting 
ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode 
for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Works fine on the simulator, though. Any ideas?

p.s. unless I'm making something very wrong here, shouldn't we reopen this?

[kurko]

For the record, it's fixed in 0.96.2. Don't forget to run rm -rf ~/Library/Caches/CocoaPods && rm -rf Pods/ before running pod install :)

[rsavutiu]

Doesn't work yet. Waiting for fixes.

[jpsim]

I can confirm that this is still an issue with the prebuilt binaries, thanks for reporting @rsavutiu.

$ (otool -l realm-swift-0.96.2/ios/swift-2.1/RealmSwift.framework/RealmSwift | grep LLVM) || echo "no bitcode"
no bitcode

Note that Realm Objective-C & Realm Swift generate bitcode binaries correctly, however, so CocoaPods users aren't affected.

[AliSoftware]

@jpsim: I've the exact same error as @kurko even as I'm using CocoaPods:

• CocoaPods 0.39.0
• Realm 0.96.2 (pod Realm, ObjC)
• Xcode 7.1

We just switched to use_frameworks! (because we'll need a Swift pod soon) and now when archiving, I see it building the .mm files from Realm but when linking the framework sources at the end it generates the following:

ld: '/<path to project>/Pods/Realm/core/librealm-ios.a(bptree-iPhoneOS-no-bitcode.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

And I checked just to be sure, ENABLE_BITCODE is set to YES on the Realm target of Pods.xcodeproj as expected (as well as on every other targets and my app).

Of course setting ENABLE_BITCODE to NO everywhere (in app + in pods via post_install hook) avoids the problem but is not ideal.

[jpsim]

@AliSoftware when you ran pod install with Realm for the first time, did you have Xcode 7+ xcode-selected? That's necessary to link the bitcode version of Realm's core. If not, could you try rm -rf Pods; pod install with Xcode 7.x selected via xcode-select -s ...?

[AliSoftware]

Thx for the follow-up.

That was on my Mac at work, and I'm quite sure xcode-select was on my /ApplicationsXcode7.app with is Xcode 7.1 or maybe 7.1.1 when I ran pod install on that project, but that was not the first time pod install was ran on the project. Maybe my coworker who did that initial pod install a while ago had Xcode 6 selected at that time indeed.

Will try to (remember to) check tomorrow morning (or try to nuke Pods and redo it), will keep you posted.

[AliSoftware]

@jpsim I can confirm this was the issue (which is logical now that I saw you use a prepare_command and that build.sh script of yours).
I removed Realm and reinstalled it with xcode-select set to Xcode 7 and now have the BitCode-enabled librealm-ios.a 👍 Thx for the tip!

Note that I think it's better to suggest users having the same problem to simply comment # pod 'Realm' from their Podfile, run pod install to uninstall it, then uncomment it and run pod install again to force the reinstallation of the pod, rather than suggesting to nuke the Pods folder, which would remove the Podfile.lock and all the pods locked versions.

Nuking the Pods folder will have the side effect that the next pod install might install latest versions of other pods when we sometimes don't want to update right away and want those pods to be locked on a specific version until we pod update them explicitly. Uninstalling just the Realm pod and installing it again doesn't generate this side effect, except just for the Realm pod itself.

[jpsim]

Thanks for the tip @AliSoftware!

[jpsim]

Turns out that our iOS, watchOS & tvOS binaries have all had bitcode since 0.96.2, but that rdar://21826157 confused us into thinking that they didn't.

#3084 will make sure we validate that our binaries continue to have bitcode in the future.

[karapigeon]

👍