Skip to content

ci(nightly): drop the musl linker override so rustc keeps the link (#683) #717

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
logbie wants to merge 1 commit into
base: main
Choose a base branch
from
Open

ci(nightly): drop the musl linker override so rustc keeps the link (#683) #717

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion .github/workflows/nightly.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -465,8 +465,19 @@ jobs:
timeout-minutes: 60
env:
TARGET: x86_64-unknown-linux-musl
# cc-rs needs this so aws-lc-sys' C and assembly compile for the musl
# target. It is deliberately NOT paired with a matching
# CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER. That variable would hand
# the link to musl-gcc - a spec-file wrapper around the host gcc whose
# specs select musl's DYNAMIC loader - so the build silently emits a
# binary carrying a PT_INTERP segment, and `-C target-feature=+crt-static`
# cannot win the link back once musl-gcc is driving it. Rust's
# x86_64-unknown-linux-musl target ships its own self-contained musl and
# static-links by default, so the correct move is to leave the link to
# rustc rather than take it away. Dropping that override is wfl#683; the
# regression it prevents is wfl#616 reappearing. The `Assert the binaries
# are statically linked` step below is what proves this held.
Comment on lines +468 to +479

@devin-ai-integration devin-ai-integration Bot Aug 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 No PR-triggered lane exercises this job, so the change is unverified until the next nightly

build-linux exists only in nightly.yml and is gated on check-for-changes.outputs.should_build == 'true', so no pull-request event can run it. The Assert the binaries are statically linked step is therefore the sole detector and it first executes after merge. If the default-linker path fails outright (e.g. host cc cannot find the self-contained musl objects), the nightly build breaks rather than degrading, which is the safer failure mode, but the merge is effectively unvalidated at review time.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines +477 to +479

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Exercise the changed linker path before merge

The build-linux job was checked and is only exercised by this scheduled/manually dispatched nightly workflow, so the unchanged static-link and Debian smoke checks do not validate this new linker selection until after it reaches main. If rustc's inferred self-contained setup cannot link the musl-gcc-built native archives on the runner, the first full nightly fails after merge; moreover, the commit's stated R0 classification is incorrect because deleting the linker override changes executable build behavior. Add a non-publishing PR or disposable staging lane that builds both binaries through this path and runs the existing PT_INTERP and Debian checks before relying on the default linker.

AGENTS.md reference: AGENTS.md:L129-L137

Useful? React with 👍 / 👎.

CC_x86_64_unknown_linux_musl: musl-gcc
Comment on lines +468 to 480

@devin-ai-integration devin-ai-integration Bot Aug 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Removing the linker override changes which compiler drives the link, and the stack-size link-arg must still pass through

With CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER gone, rustc falls back to its default linker driver (cc, i.e. the host gcc on the Blacksmith image) combined with the self-contained musl objects it ships. That path must still accept the -C link-arg=-Wl,-z,stack-size=8388608 rustflag from the cfg(target_os = "linux") block in .cargo/config.toml:10-11, which the musl target matches — the parser depends on that 8 MB stack. Host cc passes -Wl,... through unchanged, so the argument survives, but nothing in CI asserts the resulting stack-size program header, so a silent regression here would only show up as deep-recursion parser failures at runtime rather than as a red build. Worth considering an assertion on the PT_GNU_STACK/stack-size value alongside the existing PT_INTERP check.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER: musl-gcc
# Matches the BUILD_INFO the old wflbuild tarballs carried: no debug
# symbols in the shipped artifact. Also keeps target/ far below the ~30 GB
# ceiling CLAUDE.md warns about, so no disk-space dance is needed here.
Expand Down
Loading