What's the difference between `-fembed-bitcode` and BITCODE_GENERATION_MODE?

Question

I've been updating a static library to support bitcode, and from my research I found two ways to achieve that:

• Adding the fembed-bitcode flag to the Other C flags option in my project Build Settings (link)
• Adding a User-defined Setting with the key BITCODE_GENERATION_MODE set to bitcode (link)

Is there any difference between these two options?

The only difference I noted is that by using fembed-bitcode, the resulting static library for iphonesimulator will be built with full bitcode enabled (in my case, binary size changes from 5MB to 13MB, and I can check bitcode support using otool), which doesn't seem to make any difference in its usage.

Answer 1

When you build the library normally, with ENABLE_BITCODE=YES, Xcode adds the build flag -fembed-bitcode-marker to any clang invocation, placing an "empty" bitcode in the final o file.

So, if you look to the compile action in the build phase, it will look something like:

CompileC {build_path}/StaticBitcode/StaticLogger.o StaticBitcode/StaticLogger.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler cd {path}/StaticBitcode export LANG=en_US.US-ASCII export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch armv7 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fobjc-arc -fmodules -gmodules -fmodules-cache- [...] -fembed-bitcode-marker [...]

This is true to the build action (independent of the target).

When you Build & Archive, the -fembed flag is replaced by -fembed-bitcode, which really does build a Bitcode enabled binary:

CompileC {build_path}/StaticBitcode/StaticLogger.o StaticBitcode/StaticLogger.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler cd {path}/StaticBitcode export LANG=en_US.US-ASCII export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch armv7 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fobjc-arc -fmodules -gmodules -fmodules-cache- [...] -fembed-bitcode [...]

fembed-bitcode flag

Given that, if you add the -fembed-bitcode flag to the Other C flags, you will be sending two flags to the compiler during the compile time. It maybe silence some warnings that you can receive when using the library linked on another project. But, you need to check if you get the expected behavior. :)

(When I tested using the -fembed-bitcode on the Other C flags, Xcode gave the warning clang: warning: argument unused during compilation: '-fembed-bitcode-marker')

BITCODE_GENERATION_MODE

On the other hand,

If you set BITCODE_GENERATION_MODE=bitcode on your User-defined Setting, even during the build phase, the files will be compiled using the flag -fembed-bitcode.

And, if you set BITCODE_GENERATION_MODE=marker, the files will be compiled using the flag -fembed-bitcode-marker, independent of the action phase.

So, if you want to enable the bitcode to every action (build and archive), the better way to do so is using the BITCODE_GENERATION_MODE setting.

Resources

• How do I xcod ebuild a static library with Bitcode enabled?
• Apple DevForums: Bitcode and Assembly?
• SO: iOS library to BitCode