ci: add linux-aarch64 to the libretro cross-compile early-warning gate - #334
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe ChangesLibretro AArch64 cross-build
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 9✅ Passed checks (9 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
PR #331 adds a `libretro-build-linux-aarch64` job to the GitLab buildbot recipe, but a GitHub PR cannot run GitLab pipelines, so that cross-compile had zero pre-merge CI coverage -- the exact blind spot the `libretro-cross` gate exists to close (added after buildbot pipeline #91899 failed 9/10 jobs on issues reproducible in seconds on a GH runner). Add `aarch64-unknown-linux-gnu` to the gate's matrix with a per-target provisioning step. bindgen parses `libretro.h` under `--target aarch64`, glibc's `stdint.h` pulls in the arch-split `bits/libc-header-start.h`, and a stock x86_64 runner ships that header only for x86_64 -- so clang fails with `bits/libc-header-start.h not found` (the same Debian-multiarch miss the matrix note already documents for the excluded Apple targets). Installing `gcc-aarch64-linux-gnu` lands `libc6-dev-arm64-cross` under `/usr/aarch64-linux-gnu/include`; `--sysroot` plus an explicit `-isystem` send bindgen there. Still `cargo check` only -- the cross linker that package also provides is unused (linking is the buildbot's job). The header requirement was surfaced by this gate itself: the aarch64 leg failed on the runner with exactly that error, even though a local `cargo check --target aarch64-unknown-linux-gnu` had passed -- because an Arch dev host's glibc headers are not arch-split while the Debian-multiarch runner's are. That divergence is precisely the blind spot the gate exists to catch, now caught pre-merge instead of on the buildbot. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6c4bd29 to
d03f9b7
Compare
Antigravity review (Gemini via Ultra)This pull request adds Blocking issuesNone found. Suggestions
Nitpicks
Automated first-pass review by |
Summary
Adds
aarch64-unknown-linux-gnuto thelibretro-crossearly-warning gate inci.yml, giving PR-time CI coverage to the Linux aarch64 cross-compile that #331 ships to the GitLab buildbot.Why
#331 adds a
libretro-build-linux-aarch64job to.gitlab-ci.yml, but a GitHub PR can't run GitLab pipelines — so that cross-compile has no pre-merge signal here. Thelibretro-crossgate exists precisely to close that blind spot (it was added after buildbot pipeline #91899 failed 9/10 jobs on problems reproducible in seconds on a GH runner). This extends it to the target #331 introduces.Why no per-target step is needed
cargo check, notbuild: the gate never links, so ci: add a Linux aarch64 build #331's cross linker (aarch64-linux-gnu-gcc) andSTRIPoverride — which only matter at link/package time — are irrelevant here.libretro.hfrom clang's freestanding builtins: the header includes onlystdint.h/stddef.h/limits.h/stdbool.h. Verified withcargo check --release -p rustynes-libretro --target aarch64-unknown-linux-gnuon a host with zero aarch64 system headers installed — the whole graph (cpu/ppu/apu/mappers/core/rust-libretro/rustynes-libretro, bindgen included) compiled clean in ~3 min. So, unlike Android's bionic (which needs the NDK sysroot), the genericrustup target add+cargo checksteps cover it with no extra wiring.Relationship to #331
Companion to #331 (Linux aarch64 buildbot job by @WizzardSK). That PR is the feature; this is the CI insurance that keeps the aarch64 cross-compile green on every PR going forward. Different files, independent — merge order doesn't matter.
🤖 Generated with Claude Code
Summary by CodeRabbit