Implement cross-compilation to Android

[brson]

We have Android code in tree but no way to build it. It should not be all that difficult to integrate the NDK since we have some minimal cross-compile support already.

[amuxtux]

the libraries to be cross compiled are

1. libuv (for librustrt.so as dependency ), Its already here https://github.com/ILyoan/libuv
2. libcore.so
3. librustrt .so
4. libstd.so

Other tasks:

1. setup standalone ndk toolchain
   http://www.kandroid.org/ndk/docs/STANDALONE-TOOLCHAIN.html
2. specifying NDK tool chain possibly in configure phase

[brson]

As mentioned previously, this is my branch where I have been hacking on Rust's cross-compile: https://github.com/brson/rust/commits/cross2

All it does so far is add CFG_HOST_TRIPLES and CFG_BUILD_TRIPLE. Under this scheme, the target triples would be systems that we build core and std, and for the host triples we would build the entire compiler. The build triple is the architecture we bootstrap from.

[yichoi]

How can one specify multiple host-triples or target-triples? Separating with a space doesn't seem to work.

[yichoi]

It looks to me like that "for loop" of target-triples make each target directory. Assuming arm-unknown-android as target triples and x86_64-apple-darwin as host-triples, One possible way to make build directory is to adding host-triples value to target-triples, the other possible way is to modify configure script to handle host-triples and target-triples separately.

[brson]

@yichoi on the command line they are specified like ../configure --target-triples=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu

[brson]

@yichoi yeah, the host and target triples could be disjoint, though I've been assuming that target triples are a superset of host triples.

[brson]

@yichoi I pushed a cleanup commit to my cross2 branch that deletes a bunch of code to make further changes easier: brson@abb5c65

I'm going to do a little more cleanup to my cross2 branch to make sure it works like I think it does (I'm testing e.g. configure --host-triples=x86_64-unknown-linux-gnu --target-triples=x86_64-unknown-linux-gnu,i686-unknown-linuxgnu with the intent that we build cross-compiled libraries, but not a cross-compiled compiler, for the non-host-triple target-triples. I'd like to know what you think about this approach. It might be best if you take over this work since you are more familiar with what exactly we need to do for Android.

I have some examples below of how I imagine the configuration should work and the directory structure it should produce.

In the makefiles on cross2 ''host' platforms are those for which we build ompilers; 'target' platforms are the platforms are the ones the 'host' compilers target.

As an example, in a scenario where CFG_HOST_TRIPLES=x86_64-unknown-linux-gnu and CFG_TARGET_TRIPLES=x86_64-unknown-linux-gnu arm-unknown-android I would expect to see final directory output like:

x86_64-unknown-linux-gnu/
  bin/
    - x86_64 compiler, etc.
  lib/
    - x86_64 libs
    rustc/
      x86_64-unknown-linux-gnu/
      arm-unknown-android/
        bin/
          - no contents here since all our binaries depend on librustc and we won't be building a rustc to run on arm
        lib/
          librt
          libcore
          libstd      

In an even more complex scenario where we are building the entire compiler for multiple architectures (as indicated by multiple host triples) we would expect the following output (and the current build does this sort of thing already).

x86_64-unknown-linux-gnu/
  - as above
i686-unknown-linux-gnu/
  bin/
  lib/
    rustc/
      x86_64-unknown-linux-gnu/
      arm-unknown-android/
        bin/
          - no contents here since all our binaries depend on librustc and we won't be building a rustc to run on arm
        lib/
          librt
          libcore
          libstd

Some next steps (I'll leave these to you if you like):

• Each target triple needs to have it's own variables for controlling the C++ toolchain. A lot of this is defined in platform.mk
• The configure script needs a flag like --enable-android-ndk=${path} to configure the above
• rustc's linking logic in rustc::back::link will need to be modified. This code tends to be fairly platform-specific, but since the NDK uses gcc we may be able to get away with a simple change to specify which instance of gcc rustc should call to do the linking, maybe with a flag like --cc-name. If that isn't sufficient we may need to teach rustc about the android NDK itself, adding an --android-ndk-path= or similar. Perhaps this has been added already and just needs to be wired up to the makefiles.

[brson]

@graydon @nikomatsakis you may be interested in this subject

[brson]

I did some tweaks and testing to my branch and it gets through the full build under several cross-compile scenarios (just using x86 and i686), but tests.mk isn't quite right. I'm going to leave it as is until I get some feedback from @yichoi.

[brson]

@nikomatsakis asked on IRC why we don't just build the compiler for ARM. That would allow us to leave the build as it is. I had a strong belief that one wouldn't usually want a compiler to run on ARM, but that may not be true. It could be simpler to build compilers everywhere.

As an alternative to making this distinction between 'host' and 'target', which effectively just changes which binaries are built, we could teach the configure script to disable components or groups of components per target, and disable the ARM compiler by default.

[yichoi]

In case of x86_64-unknown-linux-gnu as host-triples, arm-unknown-android as target-triples. I've copied host-triples value to target-triples then made almost works except libstd of Rust building at stage2. I am investigating about that.

x86_64-unknown-linux-gnu/stage2/bin/rustc --cfg stage2 -O --target=arm-unknown-android -o x86_64-unknown-linux-gnu/stage2/lib/rustc/arm-unknown-android/lib/libstd.so /home/yichoi/rust_latest/src/libstd/std.rc && touch x86_64-unknown-linux-gnu/stage2/lib/rustc/arm-unknown-android/lib/libstd.so
Call result #4 has unhandled type i32
UNREACHABLE executed at /home/yichoi/rust_latest/src/llvm/lib/CodeGen/CallingConvLower.cpp:165!
Stack dump:
0. Running pass 'Function Pass Manager' on module 'std.rc'.

1.  Running pass 'ARM Instruction Selection' on function '@rust_uv_ip4_addr__c_stack_shim'
   

In case of x86_64-apple-darwin as host-triples, arm-unknown-android as target-triples, I am thinking a way to specify CFG_LIB_NAME=lib$(1).so or CFG_LIB_NAME=lib$(1).dylib for each target-triples. It might need to expand configuration method in platform.mk

[yichoi]

you may check https://github.com/yichoi/rust/commits/cross3. However libstd.so cannot built yet.

[ILyoan]

I believe this is because of foreign function abi.
It used to use x86 cabi to register foreign function when target was given as arm-android, but now it is default (cabi::llvm_abi_info).
I don't know the difference between two exactly, but after reverted to old setting it compiles well.
And probably we might need to implement cabi_arm.rs ?