github.com/geal/rust_on_mobile

Steps

Rust

• Create the Rust library
• export some symbols with libc (for iOS)
• use rusty-cheddar to generate the headers, or write them manually

Build for iOS

• install cargo-lipo: cargo install cargo-lipo
• install the required toolchains:
  • rustup target add aarch64-apple-ios
  • rustup target add armv7-apple-ios
  • rustup target add armv7s-apple-ios
  • rustup target add i386-apple-ios
  • rustup target add x86_64-apple-ios

iOS with CocoaPods

• install the cocoapods: sudo gem install cocoapods (cf https://cocoapods.org/ )
• use the command pod lib create InRustWeTrustKit to create the pod with an example app
• remove the .git folder in the pod
• move the podspec file at the root of the project
• change InRustWeTrustKit/Example/Podfile to point to the pod at ../../ instead of ../
• update the source_files path in the podspec from InRustWeTrustKit/Classes/**/* to InRustWeTrustKit/InRustWeTrustKit/Classes/**/*
• add the prepare_command in the podspec file to build the library
• use pod lib lint --verbose to verify the podspec file
• cd InRustWeTrustKit/Example && pod install --verbose to test building with the example app

CocoaPods have a lot of requirements to push them to the repo, like having a valid LICENSE file, making a different branch for every version, and storing every podspec file in a github repository, so be prepared to spend some time fighting those issues.

Build for Android

• download the Android NDK
• Create the rust-jni project to host the JNI interface: cargo new rust-jni. It will generate a dylib
• add the original project as dependency by path
• create the JNI export functions
• write a .cargo/config file with the following content (adjust the paths, platform and SDK version accordingly):

  [target.arm-linux-androideabi]
  ar = "/usr/local/Cellar/android-ndk/r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-ar"
  linker = "/Users/geal/dev/rust_on_mobile/rust-jni/linker-wrapper.sh"
  

• the rust-jni/linker-wrapper.sh file was a ugly hack I needed to link when a link option was unavailable with the linker version, not sure it's still needed
• cargo build --target=arm-linux-androideabi
• cp target/arm-linux-androideabi/debug/libinrustwetrust.so ../android/src/main/jniLibs/armeabi/libinrustwetrust.so
• cp target/arm-linux-androideabi/debug/libinrustwetrust.so ../android/src/main/jniLibs/armeabi-v7a/libinrustwetrust.so (we should probably build with another arch there)

Android plugin with Gradle

• create an Android library project with Android studio, put it in the android/ directory
• create the classes corresponding to the exported interface
• load the library. The dylibs should be in src/main/jniLibs/<arch>/

Loading the Android plugin

in settings.gradle:

include ':InRustWeTrust'
project(':InRustWeTrust').projectDir = new File('<PATH_TO>/rust_on_mobile/android')

in build.gradle:

dependencies {
    compile project(path: ':InRustWeTrust')
}

in gradle.properties: android.useDeprecatedNdk=true

in local.properties (update paths accordingly):

sdk.dir=/path/to/android-sdk-macosx
ndk.dir=/usr/local/Cellar/android-ndk/r11c

In the app's code, import com.geal.InRustWeTrust; and Log.d("TEST", "result: "+Integer.toString(InRustWeTrust.add(1, 2)));

Questions

Should the exported C symbols be in another crate depending on the main library?

Right now, the exported C symbols will also end up in the Android library

everything is done manually to write JNI functions right now, could it be automated a bit more?

Can we generate the Java classes? Can we avoid writing Java_com_etc? maybe with a compiler plugin

how can we generate a static library with apple's bitcode format?

The current way for iOS is to generate a so-called "universal binary" that will contain code for all targeted architectures. Apple decided that since binaries are becoming large (well, not that large compared to all the Retina aware icons, but I digress), they will make a library format containing LLVM bitcode that will be precompiled by Apple, so that you only receive the binaries for your arch when you download an app (cf http://lowlevelbits.org/bitcode-demystified/ for more info).

We can generate LLVM bitcode with Rust, but there's an incompatibility in the formats. Apple's clang uses the following version:

$ xcrun clang -v
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

From what I understand, Rust uses LLVM 3.8.1.

Apparently, The flag used to ship bitcode in the library is available from LLVM 3.8.1, but Apple used it in its 3.7 fork before contributing it back. So the bitcode generated by rustc could be incompatible:

$ cd inrustwetrust/
$ cargo rustc -- --emit llvm-ir
[...]
$ xcrun clang -c target/debug/inrustwetrust.ll
target/debug/inrustwetrust.ll:9:133: error: expected value token
  ...{ %str_slice, %str_slice, i32 } { %str_slice { i8* getelementptr inbounds ([30 x i8], [30 x i8]* @str6...
                                                                                         ^
1 error generated.

So it looks like right now, it's impossible to generate an iOS library from Rust using the bitcode format.

Exception unwinding is apparently incompatible between Rust and ObjectiveC because of compact unwinding

Linking the app can fail with the following error:

ld: too many personality routines for compact unwind to encode for architecture x86_64

This can be fixed by passing -Wl,-keep_dwarf_unwind -Wl,-no_compact_unwind as "other linker flags". From what I understand, Objective C has a different exception unwinding system that is not using the dwarf based one like Rust.

Another idea would be to remove exception unwinding from the rust code, with a panic=abort, but that means any exception would generate a crash in the Rust code, which is not a great solution.