[bluejekyll]

I agree that ostensibly it is possible. But what I would love is to see either: Apple show how to do it in a supported manner; or someone at least prove that it's possible. So far I haven't seen either.

To your comment about bitcode being stable, I don't think that bitcode stability and forward compatibility was something guarateed until 4.0.

[comex]

I mean, it's certainly possible for simple cases. I just tried:

    % cat test.rs
    fn main() {
        println!("Hello, world!");
    }
    % rustc --emit llvm-bc -C lto test.rs
    % LIB=$HOME/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib
    % xcrun --toolchain XcodeDefault clang -o test test.bc ~/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-ea49ffd3fee5264c.rlib
    warning: overriding the module target triple with x86_64-apple-macosx10.12.0 [-Woverride-module]
    1 warning generated.
    % ./test
    Hello, world!
    % rustc --version
    rustc 1.18.0-nightly (91ae22a01 2017-04-05)
    % xcrun --toolchain XcodeDefault clang --version
    Apple LLVM version 8.1.0 (clang-802.0.42)
    Target: x86_64-apple-darwin16.6.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

That's using Apple's compiler to compile bitcode from rustc. The .bc file has significant chunks of Rust's libstd embedded, so the test isn't as trivial as it seems. To embed bitcode as they want for the App Store, you can use -fembed-bitcode, except it doesn't work because liballoc_jemalloc wasn't compiled with that option (but that's trivial to fix).

I also tried compiling for iOS, which seems to work, but I didn't bother to test the resulting binary.

(As for stability, according to the announcement[1], the previous policy was that bitcode would be readable "up to and including the next major release", which was already reasonable from the perspective of keeping a third-party compiler's output compatible.)

[1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm...

[bluejekyll]

That's an excellent example, thank you!

I wonder if the dependency on jemalloc can go away once custom allocators stabilize. Then the macOS system allocator could be used.

[comex]

You could get rid of jemalloc, but on the other hand you could also just compile it with -fembed-bitcode. (It's part of the Rust standard library, so that's a bit more work. Rust code doesn't have this issue because .rlibs contain serialized ASTs, and passing -C lto makes rustc only use that rather than use the precompiled bits. In any case, it's just a matter of rebuilding.)

Incidentally, I just tried updating my nightly Rust, and it stopped working - clang started failing to read the bitcode, bailing out with a vague "error: Invalid record". This is not too surprising, because Rust just landed a big LLVM upgrade two weeks ago. Newer LLVM can read older bitcode files but not the other way around, and even though LLVM 4.0 was released months ago, Apple seems to only sync with trunk yearly, along with major Xcode releases. (You can tell based on the --version output.)

However, Rust can be built against an external LLVM (rather than the fork it uses by default), and AFAIK it tries to preserve compatibility with older versions. So it should still be possible to use the latest rustc, you just have to compile it yourself against a slightly older LLVM.

edit: corrected thinko about .rlibs