Skip to content

nightly: fix arm64 cross-link (musl cross toolchain) - #23

Closed
thepagent wants to merge 1 commit into
mainfrom
fix/nightly-arm64-cross-linker
Closed

nightly: fix arm64 cross-link (musl cross toolchain)#23
thepagent wants to merge 1 commit into
mainfrom
fix/nightly-arm64-cross-linker

Conversation

@thepagent

Copy link
Copy Markdown
Contributor

Follow-up to #21 / #22.

Problem

The first real multi-arch nightly run (33774193328) failed the arm64 legs at link time (grok, the amd64-only variant, passed — which localized it to the arm64 cross-compile):

error: linking with `cc` failed
  ... aarch64-unknown-linux-musl/.../crt1.o ...
collect2: error: ld returned 1 exit status

Root cause: musl-tools only provides the build host's musl-gcc (x86_64-linux-musl-gcc). Cross-linking a static aarch64-unknown-linux-musl binary needs an aarch64 musl linker, which it does not ship — so the link dies at crt1.o.

My earlier verification for #22 had a blind spot: I built the arm64 image natively on an M4, which is not a cross-compile, so it never exercised the cross-linker path CI uses.

Why not cargo-zigbuild

Tried it (zig 0.13 + zigbuild 0.19.8, and zig 0.14 + zigbuild 0.20.1). Both reject rustc's aarch64 linker arg:

error: unsupported linker arg: --fix-cortex-a53-843419

Fix

Install the official musl.cc cross toolchain for the target arch and point the Rust target's linker/CC at its <triple>-gcc. Strip with the toolchain's <triple>-strip (host binutils strip cannot read a foreign-arch ELF — "Unable to recognise the format"). The amd64 leg is kept identical in shape (its own musl cross toolchain instead of musl-tools), so both arches build the same way.

Verification

Built the whole image for linux/amd64,linux/arm64 from an amd64 builder context on an M4 (the real CI cross-compile path this time, not a native build):

manifest list: 2 platform manifests
amd64 leg: uname x86_64,  openab-pty & kiro-cli ELF e_machine 0x3E (x86-64)
arm64 leg: uname aarch64, openab-pty & kiro-cli ELF e_machine 0xB7 (AArch64)

Both legs compile, cross-link, strip, install the correct-arch kiro CLI, and produce a valid two-platform manifest.

Note

Depends on musl.cc being reachable at build time (retried 5x). If that host's flakiness becomes a problem, a follow-up can vendor the toolchains or switch to a mirror.

The first multi-arch nightly run (33774193328) failed the arm64 legs at
link time: `musl-tools` only ships the build host's musl-gcc
(x86_64-linux-musl-gcc), so cross-linking the static aarch64-musl binary
died at crt1.o. cargo-zigbuild is not a drop-in either — it rejects
rustc's `--fix-cortex-a53-843419` linker arg (tested zig 0.13/0.14).

Install the official musl.cc cross toolchain for the target arch and point
the Rust target's linker/CC at its `<triple>-gcc`; strip with the
toolchain's `<triple>-strip` since host binutils strip cannot read a
foreign-arch ELF ("Unable to recognise the format").

The amd64 leg was unaffected and this keeps it identical in shape (its own
musl cross toolchain instead of musl-tools), so both arches build the same
way.

Verified on an M4 by building the whole image for linux/amd64,linux/arm64
from an amd64 builder context (the real CI cross-compile path, not the
native build the earlier check used): manifest list with both platforms,
amd64 leg ELF e_machine 0x3E and arm64 leg 0xB7 for both openab-pty and
kiro-cli, uname reports x86_64 / aarch64 respectively.

Follow-up to #21 / #22.
@thepagent

Copy link
Copy Markdown
Contributor Author

Superseding this with native arm64 runners. GitHub provides free ubuntu-24.04-arm hosted runners for public repos, so the cleaner fix is to build each arch on its own native runner (no cross toolchain, no QEMU, no musl.cc dependency) and merge into a manifest — which also lets the arm64 leg be smoke-tested for real. New PR to follow.

@thepagent thepagent closed this Sep 3, 2026
@thepagent
thepagent deleted the fix/nightly-arm64-cross-linker branch September 3, 2026 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants