"cannot produce dylib for rustc_driver v0.0.0 ...
as the target riscv64gc-unknown-linux-musl
does not support these crate types"
#110511
Labels
A-linkage
Area: linking into static, shared libraries and binaries
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
O-musl
Target: The musl libc
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-cargo
Relevant to the cargo team, which will review and decide on the PR/issue.
I'm cross-compiling Rust for
riscv64gc-unknown-linux-musl
with the followingconfig.toml
:Executing:
RUSTFLAGS="-Clink-args=-lgcc" ./x.py build --host riscv64gc-unknown-linux-musl --target riscv64gc-unknown-linux-musl --verbose
the output is:
If I edit the
compiler/rustc_driver/Cargo.toml
file as suggested here, it works.I filed a separate bug, #110509, about the error message, but even aside from the diagnostics, this behavior seems wrong. My understanding of what the error means is "we can't build the extended Rust tool set, because that requires a dynamically linked
rustc_driver
crate, which can't be built for a target with a statically linked C runtime" (if my understanding is wrong, let me know.) That seems like a condition that should be detected at config time, not midway through the build. Moreover, if this really is an intrinsic limitation of compiling Rust for statically linked targets, it seems weird to me that thecompiler/rustc_driver/Cargo.toml
patch would fix it. On the other hand, if it's not an intrinsic limitation, then manually patching this file shouldn't be necessary and the preferred crate type forrustc_driver
should be auto-detected based on the target and target options.Hope this makes sense, but if further clarification is needed, let me know!
The text was updated successfully, but these errors were encountered: