[suchintan]

https://github.com/Skyvern-AI/rustwright-cloud/pull/229

[claude]

Summary

Small, self-contained addition of a tools/zig-cc wrapper script for cross-compiling to aarch64-unknown-linux-gnu with Zig's cc. The script itself is reasonable, but it doesn't appear to be wired up anywhere yet, and it duplicates logic that already exists (and diverges) in four release workflows.

🔴 Critical Issues (0)

None.

🟡 Suggestions (2)

• Script appears to be dead code / not wired in. .github/workflows/release-npm.yml, release-gem.yml, release-maven.yml, and release-nuget.yml all still generate their own inline heredoc copy of this script into $RUNNER_TEMP/zig-cc at build time — none of them reference tools/zig-cc. As-is, this PR adds a script nothing in the repo invokes. If the intent (per the PR title "support stable Rust aarch64 linker") is for CI to actually use this fixed version, the four workflows need a follow-up to cat/copy tools/zig-cc (or invoke it directly) instead of using their own embedded copies — otherwise the -Wl,--fix-cortex-a53-843419 fix and python-zig fallback this file adds never take effect.
• Duplicated/diverging logic across 5 locations. The arg-filtering loop now exists in tools/zig-cc plus 4 copy-pasted inline versions in the workflow files, and they've already drifted (the inline versions lack the cortex-a53 filter and the python-zig fallback). Once wired in, consider having the workflows source this single file instead of embedding their own copy, so future linker fixes only need to land in one place.

📝 Minor / Style (2)

• python-zig as a fallback binary name is unusual — double check this is the intended executable name (vs. e.g. python -m ziglang) since a wrong fallback would silently fail with a confusing "not found" error only on machines lacking a zig binary on PATH.
• The -Wl,--fix-cortex-a53-843419 filter is matched as an exact literal case arm; if rustc/cc-rs ever emits it combined with other flags in a single -Wl,a,b token, this filter won't catch it. Probably fine given current toolchain behavior, but worth a comment noting the assumption if it isn't already documented elsewhere (this repo appears to sync tools/ from a private rustwright-cloud repo, so the assumption may already be validated there).