Open maurer opened 4 months ago
r? @Kobzol
(rustbot has picked a reviewer for you, use r? to override)
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.
cc @chriswailes
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.
@rustbot ready
@bors r+ rollup=iffy
: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...
:broken_heart: Test failed - checks-actions
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
.
@bors r=Mark-Simulacrum,workingjubilee
: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...
:boom: Test timed out
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.
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...
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.
@bors r-
@maurer any updates on this? thanks
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:
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/crashesaarch64
development image does not support 32-bit execution. We'll need a separate system-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).
Some changes occurred in tests/codegen/sanitizer
cc @rust-lang/project-exploit-mitigations, @rcvalle
The job mingw-check-tidy
failed! Check out the build log: (web) (plain)
@Mark-Simulacrum , since you uploaded the files last time (so I know you have the power), can you upload with both .lock
files (now that I created two of them, with different contents)? Once that's done, I'll pull the two hack commits I've got on for testing off and we should finally be good.
@rustbot ready (It is not actually ready, but it requires reviewer action to progress)
Happy to upload some files to our mirror, but I'm not sure where I should mirror them from or exactly which files need to be uploaded. Can you clarify?
Specifically, I would like you to run:
src/ci/docker/scripts/android-sdk-manager.py update-mirror src/ci/docker/host-x86_64/aarch64-android/android-sdk.lock
src/ci/docker/scripts/android-sdk-manager.py update-mirror src/ci/docker/host-x86_64/arm-android/android-sdk.lock
with this CL pulled down.
This will fetch the Android images + emulator from google's repositories and upload them to your buckets. I'll then drop DO NOT SUBMIT: Hack SDK manager to not use buckets from the PR to make sure it worked (let GHA run), and then drop DO NOT SUBMIT - force run aarch64-android and arm-android and it should be good for submission.
Alright, that should be done.
OK, ready for review - I've stripped both hack commits off.
:umbrella: The latest upstream changes (presumably #123337) made this pull request unmergeable. Please resolve the merge conflicts.
@maurer sorry about that, can you rebase this?
@bors r+ rollup=never
:pushpin: Commit c1ac0c8cfb95e129466aefa79d6a5bb324609668 has been approved by Mark-Simulacrum
It is now in the queue for this repository.
:hourglass: Testing commit c1ac0c8cfb95e129466aefa79d6a5bb324609668 with merge 5b05a5aed7696ccb3d8487d528bc997aa7a175b4...
The job aarch64-gnu
failed! Check out the build log: (web) (plain)
:broken_heart: Test failed - checks-actions
@bors retry
aarch64 runner reboot
:hourglass: Testing commit c1ac0c8cfb95e129466aefa79d6a5bb324609668 with merge bb06083720fb43d8cc4f4b948769f06c68d54265...
The job aarch64-android
failed! Check out the build log: (web) (plain)
:broken_heart: Test failed - checks-actions
oddly specific failure.
That looks like a pointer getting used as an index - that number is 0xffffff8aee5d1001
. I don't think it's related to anything in this CL, but I can try re-running things manually tomorrow...
The one thing that it could be in this change is that aarch64-android
is using a new emulator, which means a different version of qemu
. The probe tests I ran should have found that though, unless we had a codegen change in the last ~week that this emulator mis-executes.
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: