rustc: android cross compilation

[ILyoan]

rustc - android cross compilation with --target=arm-unknown-android option

it also has cmake build system to build rustc and runtime libraries for target.

libuv for android is on git://github.com/ILyoan/libuv.git

it has some known problems yet

• rustrt for android does not use morestack
• compiling libcore with -O option cause a segmentation fault on android

[bblum]

hi, wow, great work guys.

I have to wonder if the ARM memory semantics are handled correctly in some of the concurrency libraries? namely, as i mentioned in #1858, the pipes send() implementation follows the classic "fill a buffer, set a flag" pattern, which needs some sort of barrier with noncoherent memory models. maybe this seems like a small nitpick next to the colossal size of the pull request, but i don't see libcore/pipes.rs among the files changed.

[ILyoan]

@bblum We should have check that issue! I'll check it out

as you know, this version is not a stable one. perhaps it has lots of potential problems
I think it is premature yet but we just want to get reviews from you guys :)

[brson]

Yay! Thanks so much for this!

[eholk]

@bblum: As far as I know, the LLVM atomic instructions are supposed to insert the necessary barriers to provide the semantics you request. I think I picked the right variant, but since we've only tried it on x86 memory models it's hard to test and know for sure.

[brson]

I will merge as much of this as I can this week.

[ILyoan]

@brson: That sounds good!!
@bblum: I need more study about the issue. honestly i'm not a arm expert so I'd appreciate some help.

[brson]

@ILyoan I am planning on cherry picking the non-CMake parts of this branch. We need to have further discussion about how to handle the CMake files. On our end we still are not interested in transitioning our build system to CMake, so we need to decide whether we're going to keep these files in tree, whether we're going to support and/or maintain them, and whether we should dedicate build automation to them.

I don't want this to hinder your progress, so I'd like to resolve this question soon.

[brson]

I've opened #4404 about JNI issues.

[brson]

Also opened #4405 about completing the stubs in rust_android_dummy.cpp

[brson]

It's taking a while to get this merged because of unrelated problems with the bots (buildbot.rust-lang.org), but here's the integration branch I've been working off of: https://github.com/brson/rust/tree/arm. It rebases out the CMake-related changes.

[ILyoan]

@brson thanks a lot. if you need our hand please let us know.

[brson]

OK, I've made some progress here. Let me explain what I've done, because I've shuffled commits around, rebased, etc.

First, I merged to incoming all the work on this branch that doesn't involve CMake, so that work has landed. Thanks! Note that I have not personally tested an ARM build yet, so it's possible that I broke things in the process.

Then I rebased the remaining CMake bits into a single commit and pushed to my branch here: https://github.com/brson/rust/tree/cmake. I recommend rebasing your work off of that branch. We still haven't reached a conclusion about what to do about CMake, though my inclination is to keep it in tree since it's self-contained.

Finally, since Android support is still immature and we can't officially support it yet, I did not want to put instructions in the README file. Instead I've started a wiki page: https://github.com/mozilla/rust/wiki/Doc-building-for-android.

I'll leave this pull request open until we resolve the CMake issues.

[brson]

I added #4513 to modify our build system for Android cross compile and intend to work on it soon. Closing.

[bblum]

I gotta say, you guys are all superheroes