fix(docker): separate host/target CC wrappers; drop Swatinem/rust-cache - #11
Merged
Merged
Conversation
The push-to-main build failed again after the cache-id fix, this time with: ld: .../liblibsqlite3_sys-*.rlib: file in wrong format (Relocations in generic ELF (EM: 183) -- EM_AARCH64 -- while linking a host-native x86_64 proc-macro artifact). Root cause: CC_x86_64_unknown_linux_musl and CC_aarch64_unknown_linux_musl both pointed at the same musl-cc script, which read one global /zig_target.txt written once from $TARGETARCH. Build scripts and proc-macro crates (e.g. sqlx-macros) always compile for the HOST triple (x86_64, since this stage is pinned to --platform=$BUILDPLATFORM) regardless of the cross --target for the final binary. On the arm64 build, that shared file said aarch64-linux-musl, so host-triple C compiles (like libsqlite3-sys's build script, needed by sqlx-macros) got wrongly compiled for aarch64 too, then failed to link into the host-native x86_64 proc-macro artifact. Worked "by accident" on the amd64 build only because host == target there. Generates one wrapper per triple (musl-cc-x86_64, musl-cc-aarch64, and the g++ equivalents) with the zig target hardcoded at generation time, so CC selection is no longer ambiguous. Verified locally: built just the chef stage and confirmed each wrapper embeds the correct -target. Also rewrites the wrapper-generation RUN using BuildKit's heredoc syntax (# syntax=docker/dockerfile:1) instead of backslash-continued shell mixed with an embedded cat<<WRAP heredoc -- the old form's lack of a trailing backslash on the heredoc's last line caused the Dockerfile's line-continuation parser to lose track of where the RUN instruction ended.
Reduces reliance on community-maintained third-party actions in the supply chain. actions/cache is GitHub's own official action; manually configuring the cache paths (~/.cargo/registry, ~/.cargo/git, target/) keyed on Cargo.lock gives equivalent caching behavior to what Swatinem/rust-cache was doing under the hood.
vishwateja-angirekula
self-requested a review
July 9, 2026 07:38
vishwateja-angirekula
approved these changes
Jul 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
CC_x86_64_unknown_linux_muslandCC_aarch64_unknown_linux_muslboth pointed at the samemusl-ccwrapper script, which read one global/zig_target.txtwritten once from$TARGETARCH. Build scripts and proc-macro crates (e.g.sqlx-macros) always compile for the host triple (x86_64, since the chef stage is pinned to--platform=$BUILDPLATFORM) regardless of the cross--targetfor the final binary. On the arm64 build, that shared file saidaarch64-linux-musl, so host-triple C compiles (e.g.libsqlite3-sys's build script, needed bysqlx-macros) got wrongly compiled for aarch64 too, then failed to link into the host-native x86_64 proc-macro artifact (file in wrong format,EM_AARCH64relocations). Worked "by accident" on amd64 only because host == target there.musl-cc-x86_64,musl-cc-aarch64, and theg++equivalents) with the zig target hardcoded at generation time instead of read from a shared file.chefstage on this branch and confirmed each generated wrapper embeds the correct-target.RUNto BuildKit's heredoc syntax (# syntax=docker/dockerfile:1) — the old backslash-continued form combined with an embeddedcat <<WRAPheredoc caused the Dockerfile parser to lose track of where theRUNinstruction ended (it readchmodon the next line as a bogus top-level instruction).Swatinem/rust-cache@v2(community-maintained third-party action) fromclippy/test, replaced with GitHub's ownactions/cache@v4manually configured for the same cache paths (~/.cargo/registry,~/.cargo/git,target/) keyed onCargo.lock.Test plan
chefstage confirms both wrapper scripts have the correct hardcoded-target