Dual target Android Rust compiler

Hi,

Please accept my apologies if this is not the correct forum for this question.

I’ve successfully built a single Rust compiler that targets the various iOS triples, and now I’m turning my attention to Android. I want a single Rust compiler that targets the two ARM Android triples. For background, my host is Darwin.

I have built separate stand-alone Rust compilers for arm-linux-androideabi and for aarch64-linux-android, but I am flummoxed by how to build a single Rust compiler that targets both triples.

The (perceived?) issue is that I can only configure rust with a single Android standalone NDK path (using the --android-cross-path option), whereas I think I need to pass in two standalone NDK paths, one for each of the triple.

i.e., I am configuring rust thus:

./configure --target=arm-linux-androideabi,aarch64-linux-android --android-cross-path=/path/to/which-ndk

but I think I ought to be able to configure it thus (hypothetical syntax):

./configure --target=arm-linux-androideabi,aarch64-linux-android --arm-linux-androideabi-ndk=/path/to/arm-linux-androideabi-ndk --aarch64-linux-android-ndk=/path/to/aarch64-linux-android-ndk

The directory trees of the aarch64-linux-android-4.9 and arm-linux-androideabi-4.9 standalone NDKs collide in only a few places (the triple is used for most filenames/dirnames), so it is tempting to install both NDKs to a single directory and “hope for the best”. The places where they differ, however, seem important. Both standalone NDKs contain a sysroot directory with custom header files and libraries for each triple, these are named identically in both NDKs and cannot coexist within a single directory tree.

I’m not talented enough to know whether the rust compilation process uses files from the standalone NDK sysroot directory or not. Thus my dilemma.

The questions, at last:

Has anyone successfully built (and used) a single Rust compiler that targets both ARM Android triples mentioned above?

If so, how did you setup the dual standalone NDKs?

I modified the Rust configure script (and some mk files) to use separate NDKs for each Android ARM triple, and it works perfectly (well, rustc builds, I haven't tried using it yet!).

To determine if my modifications to the Rust build scripts were actually necessary to produce this multi-Android-target compiler, I nuked the sysroot directory from each of the two NDK directories, and attempted to rebuild rustc. The build failed.

Thus, where I previously said ...

I'm not talented enough to know whether the rust compilation process uses files from the standalone NDK sysroot directory or not.

... I now can say with confidence, the rust compilation process uses files from the NDK sysroot directory. Thus, it seems likely that combining NDKs into a single NDK directory is a very bad idea.

Without changes to the build process, I think that building a multi-Android-target Rust compiler is impossible. I'd be interested to hear from anyone to the contrary.

Is there any interest in my submitting a pull request to allow others to build similar multi-Android-target Rust compilers?

Is there any interest in my submitting a pull request to allow others to build similar multi-Android-target Rust compilers?

Yes, this seems very interesting.

The tarballs Servo produces can cross compile to three targets. (directory here).

I think @larsberg has a script to do this

We have the same problem that @mark_buer mentioned - if we wanted two of those targets to be against different Android versions, we need his patches to do that correctly, because each one relies on env variables/config flags that are not per-target today.

I know that @edunham and @brson have a plan to allow “merging” of target-specific outputs, so that you could instead build rustc multiple times with the different flags and then merge them afterwards, which might be an alternative if the full set of autotools changes are too insane.

Pull request has been submitted here https://github.com/rust-lang/rust/pull/27173

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.