Skip to content

Conversation

Gelbpunkt
Copy link
Contributor

I can't really make sense of this part.

For musl targets that default to static linkage, crt-static is set as a target feature and cc-rs should be able to correctly infer that -static should be used. However, you cannot compile rustc or run the tests with +crt-static, so you'd have to disable it in bootstrap.toml anyways, bypassing this codepath entirely.

But for targets that are defaulting to dynamic linkage, hardcoding -static for all musl targets in cc_detect just doesn't make sense. It breaks the run-make tests because the compiler defaults (and is configured!) to dynamically link dylibs, but the cc-rs configuration is hardcoded to link them statically, which will fail.

This fixes running ./x.py test --stage 2 on musl hosts that default to dynamic linkage and when not explicitly setting crt-static = false in bootstrap.toml (since that should be the default!).

I can't really make sense of this part. For musl targets that default to
static linkage, crt-static is set as a target feature and cc-rs should
be able to correctly infer that -static should be used. However, you
cannot compile rustc or run the tests with +crt-static, so you'd have to
disable it in bootstrap.toml anyways, bypassing this codepath entirely.
But for targets that are defaulting to dynamic linkage, hardcoding
-static for all musl targets in cc_detect just doesn't make sense. It
breaks the run-make tests because the compiler defaults (and is
configured!) to dynamically link dylibs, but the cc-rs configuration is
hardcoded to link them statically, which will fail.

Signed-off-by: Jens Reidel <adrian@travitia.xyz>
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Sep 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 15, 2025

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@Mark-Simulacrum
Copy link
Member

@bors r+

I think this seems correct.

@bors
Copy link
Collaborator

bors commented Sep 21, 2025

📌 Commit 3847786 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 21, 2025
Zalathar added a commit to Zalathar/rust that referenced this pull request Sep 22, 2025
…=Mark-Simulacrum

bootstrap: Don't force -static for musl targets in cc-rs

I can't really make sense of this part.

For musl targets that default to static linkage, crt-static is set as a target feature and cc-rs should be able to correctly infer that -static should be used. However, you cannot compile rustc or run the tests with +crt-static, so you'd have to disable it in bootstrap.toml anyways, bypassing this codepath entirely.

But for targets that are defaulting to dynamic linkage, hardcoding -static for all musl targets in cc_detect just doesn't make sense. It breaks the run-make tests because the compiler defaults (and is configured!) to dynamically link dylibs, but the cc-rs configuration is hardcoded to link them statically, which will fail.

This fixes running `./x.py test --stage 2` on musl hosts that default to dynamic linkage and when not explicitly setting `crt-static = false` in bootstrap.toml (since that should be the default!).
bors added a commit that referenced this pull request Sep 22, 2025
Rollup of 8 pull requests

Successful merges:

 - #146317 (Add panic=immediate-abort)
 - #146397 (std_detect on Darwin AArch64: update features)
 - #146594 (bootstrap: Don't force -static for musl targets in cc-rs)
 - #146791 (emit attribute for readonly non-pure inline assembly)
 - #146831 (Support ctr and lr as clobber-only registers in PowerPC inline assembly)
 - #146838 (Introduce "wrapper" helpers to rustdoc)
 - #146846 (btree InternalNode::new safety comments)
 - #146858 (Make mips64el-unknown-linux-muslabi64 link dynamically)

r? `@ghost`
`@rustbot` modify labels: rollup
Zalathar added a commit to Zalathar/rust that referenced this pull request Sep 22, 2025
…=Mark-Simulacrum

bootstrap: Don't force -static for musl targets in cc-rs

I can't really make sense of this part.

For musl targets that default to static linkage, crt-static is set as a target feature and cc-rs should be able to correctly infer that -static should be used. However, you cannot compile rustc or run the tests with +crt-static, so you'd have to disable it in bootstrap.toml anyways, bypassing this codepath entirely.

But for targets that are defaulting to dynamic linkage, hardcoding -static for all musl targets in cc_detect just doesn't make sense. It breaks the run-make tests because the compiler defaults (and is configured!) to dynamically link dylibs, but the cc-rs configuration is hardcoded to link them statically, which will fail.

This fixes running `./x.py test --stage 2` on musl hosts that default to dynamic linkage and when not explicitly setting `crt-static = false` in bootstrap.toml (since that should be the default!).
bors added a commit that referenced this pull request Sep 22, 2025
Rollup of 10 pull requests

Successful merges:

 - #145411 (regression test for Cow<[u8]> layout)
 - #146317 (Add panic=immediate-abort)
 - #146397 (std_detect on Darwin AArch64: update features)
 - #146594 (bootstrap: Don't force -static for musl targets in cc-rs)
 - #146652 (Port `feature` to the new attribute system)
 - #146791 (emit attribute for readonly non-pure inline assembly)
 - #146831 (Support ctr and lr as clobber-only registers in PowerPC inline assembly)
 - #146838 (Introduce "wrapper" helpers to rustdoc)
 - #146846 (btree InternalNode::new safety comments)
 - #146858 (Make mips64el-unknown-linux-muslabi64 link dynamically)

r? `@ghost`
`@rustbot` modify labels: rollup
Zalathar added a commit to Zalathar/rust that referenced this pull request Sep 22, 2025
…=Mark-Simulacrum

bootstrap: Don't force -static for musl targets in cc-rs

I can't really make sense of this part.

For musl targets that default to static linkage, crt-static is set as a target feature and cc-rs should be able to correctly infer that -static should be used. However, you cannot compile rustc or run the tests with +crt-static, so you'd have to disable it in bootstrap.toml anyways, bypassing this codepath entirely.

But for targets that are defaulting to dynamic linkage, hardcoding -static for all musl targets in cc_detect just doesn't make sense. It breaks the run-make tests because the compiler defaults (and is configured!) to dynamically link dylibs, but the cc-rs configuration is hardcoded to link them statically, which will fail.

This fixes running `./x.py test --stage 2` on musl hosts that default to dynamic linkage and when not explicitly setting `crt-static = false` in bootstrap.toml (since that should be the default!).
bors added a commit that referenced this pull request Sep 22, 2025
Rollup of 9 pull requests

Successful merges:

 - #145411 (regression test for Cow<[u8]> layout)
 - #146317 (Add panic=immediate-abort)
 - #146397 (std_detect on Darwin AArch64: update features)
 - #146594 (bootstrap: Don't force -static for musl targets in cc-rs)
 - #146791 (emit attribute for readonly non-pure inline assembly)
 - #146831 (Support ctr and lr as clobber-only registers in PowerPC inline assembly)
 - #146838 (Introduce "wrapper" helpers to rustdoc)
 - #146846 (btree InternalNode::new safety comments)
 - #146858 (Make mips64el-unknown-linux-muslabi64 link dynamically)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Sep 22, 2025
Rollup of 9 pull requests

Successful merges:

 - #145411 (regression test for Cow<[u8]> layout)
 - #146317 (Add panic=immediate-abort)
 - #146397 (std_detect on Darwin AArch64: update features)
 - #146594 (bootstrap: Don't force -static for musl targets in cc-rs)
 - #146791 (emit attribute for readonly non-pure inline assembly)
 - #146831 (Support ctr and lr as clobber-only registers in PowerPC inline assembly)
 - #146838 (Introduce "wrapper" helpers to rustdoc)
 - #146846 (btree InternalNode::new safety comments)
 - #146858 (Make mips64el-unknown-linux-muslabi64 link dynamically)

r? `@ghost`
`@rustbot` modify labels: rollup
@Zalathar
Copy link
Contributor

Possibly failed in rollup? #146876 (comment)

@bors r-

I'll run a try job to double-check.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 22, 2025
@Zalathar
Copy link
Contributor

@bors try jobs=dist-i586-gnu-i586-i686-musl

rust-bors bot added a commit that referenced this pull request Sep 22, 2025
bootstrap: Don't force -static for musl targets in cc-rs

try-job: dist-i586-gnu-i586-i686-musl
@rust-bors

This comment has been minimized.

@rust-log-analyzer
Copy link
Collaborator

The job dist-i586-gnu-i586-i686-musl failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
---- [run-make] tests/run-make/c-link-to-rust-va-list-fn stdout ----

error: rmake recipe failed to complete
status: exit status: 101
command: cd "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/c-link-to-rust-va-list-fn/rmake_out" && env -u RUSTFLAGS -u __RUSTC_DEBUG_ASSERTIONS_ENABLED -u __STD_DEBUG_ASSERTIONS_ENABLED AR="ar" BUILD_ROOT="/checkout/obj/build/x86_64-unknown-linux-gnu" CC="/musl-i686/bin/musl-gcc" CC_DEFAULT_FLAGS="-ffunction-sections -fdata-sections -fPIC -m32 -march=i686 -Wl,-melf_i386 -Wa,-mrelax-relocations=no" CXX="musl-g++" CXX_DEFAULT_FLAGS="-ffunction-sections -fdata-sections -fPIC -m32 -march=i686 -Wl,-melf_i386" HOST_RUSTC_DYLIB_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" LD_LIBRARY_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib" LD_LIB_PATH_ENVVAR="LD_LIBRARY_PATH" LLVM_BIN_DIR="/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/bin" LLVM_COMPONENTS="aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard cgdata codegen codegentypes core coroutines coverage csky cskyasmparser cskycodegen cskydesc cskydisassembler cskyinfo debuginfobtf debuginfocodeview debuginfodwarf debuginfodwarflowlevel debuginfogsym debuginfologicalview debuginfomsf debuginfopdb demangle dlltooldriver dwarfcfichecker dwarflinker dwarflinkerclassic dwarflinkerparallel dwp engine executionengine extensions filecheck frontendatomic frontenddirective frontenddriver frontendhlsl frontendoffloading frontendopenacc frontendopenmp fuzzercli fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo hipstdpar instcombine instrumentation interfacestub interpreter ipo irprinter irreader jitlink libdriver lineeditor linker loongarch loongarchasmparser loongarchcodegen loongarchdesc loongarchdisassembler loongarchinfo lto m68k m68kasmparser m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts objcopy object objectyaml option orcdebugging orcjit orcshared orctargetprocess passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvtargetmca runtimedyld sandboxir scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target targetparser telemetry textapi textapibinaryreader transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86targetmca xray xtensa xtensaasmparser xtensacodegen xtensadesc xtensadisassembler xtensainfo" LLVM_FILECHECK="/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" PYTHON="/usr/bin/python3" RUSTC="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" RUSTC_LINKER="/musl-i686/bin/musl-gcc" RUSTDOC="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" SOURCE_ROOT="/checkout" TARGET="i686-unknown-linux-musl" TARGET_EXE_DYLIB_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/i686-unknown-linux-musl/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/c-link-to-rust-va-list-fn/rmake"
stdout: none
--- stderr -------------------------------

thread 'main' panicked at /checkout/tests/run-make/c-link-to-rust-va-list-fn/rmake.rs:19:5:
failed to get output of finished process: Os { code: 2, kind: NotFound, message: "No such file or directory" }
---
   6: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
------------------------------------------

---- [run-make] tests/run-make/c-link-to-rust-va-list-fn stdout end ----

failures:
    [run-make] tests/run-make/c-link-to-rust-va-list-fn

test result: FAILED. 137 passed; 1 failed; 293 ignored; 0 measured; 0 filtered out; finished in 38.93s

@rust-bors
Copy link

rust-bors bot commented Sep 22, 2025

💔 Test for 0cade8a failed: CI. Failed jobs:

@Gelbpunkt
Copy link
Contributor Author

Gelbpunkt commented Sep 23, 2025

Hmm, I'm not really sure what to do here. It seems like cc-rs actually isn't able to guess the -static flag for the target because fill_target_compiler runs way too early and CARGO_CFG_TARGET_FEATURE is populated for the host at that time, not for the target, so the test from a -gnu host to a -musl target with only a static library won't work.

I would instead suggest that I readd the hardcoded static flag for now, but only if the target isn't the host target (which is the case I'm trying to fix).

Alternatively we could mayhaps look at the target's configured crt-static in the run-make tests and add -static on a case-by-case basis if it is configured?

WDYT?

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 24, 2025
@Mark-Simulacrum
Copy link
Member

CARGO_CFG_TARGET_FEATURE is populated for the host at that time, not for the target

I think that env variable will always be set for the host during bootstrap, since that's what we're actually running on? Unless I missed something. It seems wrong for cc to look at it all.

My sense is that perhaps there's something to be fixed upstream in cc here? cc @NobodyXu

@NobodyXu
Copy link
Contributor

If you can generate the static information from rust , then you can modify our gen-target-info to include this information

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants