rust-lang
Update Android in CI
We are currently using a 10+ year old Android image, and it has caused trouble when working on #120326.
Our current NDK (25) only supports API 19+, so we were already out of spec. This PR:
- Bumps the API used by the emulator in CI to 21, as per NDK-26's release notes deprecating 19 and 20 as targets.
- Activates aarch64 testing on the emulator, since the base image is now a 64-bit image.
- Bumps the NDK to 26b
r? @pietroalbini
Pietro, I've added you explicitly since you're the only one to ever touch this lockfile, which means you're likely to be the one who can run update-mirror, which I lack the credentials for.
The new files should be uploaded to the mirror. However, I'd like to get a +1 from another android target maintainer on this PR before moving ahead.
cc @chriswailes @mgeisler (per platform support docs)
Happy to see this land, as it looks like it will also allow simplifying away https://github.com/rust-lang/backtrace-rs/pull/570 from backtrace-rs, too.
ping @Mark-Simulacrum - it looks like it still says "waiting on author", but Chris has LGTM'd.
:pushpin: Commit 7c39eee98f853611ff42da35bb3af9a66180eadc has been approved by Mark-Simulacrum
It is now in the queue for this repository.
:hourglass: Testing commit 7c39eee98f853611ff42da35bb3af9a66180eadc with merge 23c8dec56714406a898fcc56742ba5708546a693...
The job dist-android failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)
Failed about here, it seems:
Executing python3 ../x.py dist --host= --target arm-linux-androideabi,armv7-linux-androideabi,thumbv7neon-linux-androideabi,i686-linux-android,aarch64-linux-android,x86_64-linux-android
+ python3 ../x.py dist --host= --target arm-linux-androideabi,armv7-linux-androideabi,thumbv7neon-linux-androideabi,i686-linux-android,aarch64-linux-android,x86_64-linux-android
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.04s
thread 'main' panicked at src/core/sanity.rs:59:13:
couldn't find required command: "/android/ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi19-clang"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I missed the cc_detect logic the first time around - it was still attempting to pick an API 19 linker for 32-bit.
@rustbot ready
This PR modifies config.example.toml.
If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.
:pushpin: Commit a9724f36febccbbc24b7c38975df1b3d52ea05e2 has been approved by Mark-Simulacrum,workingjubilee
It is now in the queue for this repository.
The change in cc_detect caused me to inspect and notice that config.toml.example had a ref to n25b so I asked maurer to update that, which led to the etc. etc. There are some other necessary followups too, but this CI change should land independently.
:hourglass: Testing commit a9724f36febccbbc24b7c38975df1b3d52ea05e2 with merge cc89f616fb86b6a981160880f78e88c839bbf4ee...
The fact this timeout was on, specifically, the aarch64-android job, makes me feel like this was not a spurious error, but I have no proof for that.
A job failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)
Seems possible that it's a real failure. Are you aware of any workflows for trying to reproduce locally? I would have expected that even a timeout would have logs leading up to the failing step...
https://rustc-dev-guide.rust-lang.org/tests/docker.html
https://github.com/rust-lang-ci/rust/actions/runs/8411885535/job/23032016177 for the logs.
The logs just terminate somewhat cryptically here:
Building stage2 library artifacts (x86_64-unknown-linux-gnu -> arm-linux-androideabi)
[TIMING] core::build_steps::compile::Std { target: arm-linux-androideabi, compiler: Compiler { stage: 2, host: x86_64-unknown-linux-gnu }, crates: [], force_recompile: false, extra_rust_args: [], is_for_mir_opt_tests: false } -- 46.623
REMOTE copy libs to emulator (arm-linux-androideabi)
Building stage2 tool remote-test-server (x86_64-unknown-linux-gnu -> arm-linux-androideabi)
Compiling remote-test-server v0.1.0 (/checkout/src/tools/remote-test-server)
[RUSTC-TIMING] remote_test_server test:false 0.682
Finished `release` profile [optimized] target(s) in 0.85s
[TIMING] core::build_steps::tool::ToolBuild { compiler: Compiler { stage: 2, host: x86_64-unknown-linux-gnu }, target: arm-linux-androideabi, tool: "remote-test-server", path: "src/tools/remote-test-server", mode: ToolStd, source_type: InTree, extra_features: [], allow_features: "" } -- 0.864
[TIMING] core::build_steps::tool::RemoteTestServer { compiler: Compiler { stage: 2, host: x86_64-unknown-linux-gnu }, target: arm-linux-androideabi } -- 0.001
Building stage0 tool remote-test-client (x86_64-unknown-linux-gnu)
Compiling remote-test-client v0.1.0 (/checkout/src/tools/remote-test-client)
[RUSTC-TIMING] remote_test_client test:false 0.579
Finished `release` profile [optimized] target(s) in 0.73s
[TIMING] core::build_steps::tool::ToolBuild { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu }, target: x86_64-unknown-linux-gnu, tool: "remote-test-client", path: "src/tools/remote-test-client", mode: ToolBootstrap, source_type: InTree, extra_features: [], allow_features: "" } -- 0.746
[TIMING] core::build_steps::tool::RemoteTestClient { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu }, target: x86_64-unknown-linux-gnu } -- 0.001
waiting for device to come online
* daemon not running; starting now at tcp:5037
* daemon started successfully
Error: The operation was canceled.
The log analyzer decided not to report it because its heuristics meant this was decided to not be very informative, which... is correct, honestly. With a "wonderful" log report like that, it's hard to actually rule out anything. Though, it probably should have decided to just fork over those last few lines anyways.
:umbrella: The latest upstream changes (presumably #124026) made this pull request unmergeable. Please resolve the merge conflicts.
Sorry, I've been on vacation for the last two weeks. I should have a chance to investigate this further some time this week.
Brief update:
- We're going to need to upload
emulator emulator-linux_x64-11772612.zip 974ad0591834a9fa3db307e49cdba352462e5f1e- the emulator that was in the previous change has a bug when running in headless mode that leads to segfaults/crashes - The
aarch64development image does not support 32-bit execution. We'll need a separatesystem-images;android-21;default;armeabi-v7a.
Would folks prefer: a. Updating the android builder to launch two VMs, and do both arm32 and aarch64 testing on them b. Split into two builders, and keep to the 'one external runner per builder' paradigm that's been in use.
As far as I can tell, b is closer to what we've done elsewhere, so it's what I'll configure if I don't hear otherwise. I'll update the change once I have something passing (with the caveat of a hack I'll need until the mirror is updated).