We're adding AddressSanitizer support to our project and need to flip -Ctarget-feature=+crt-static to -crt-static for ASAN builds (ASAN requires dynamic linking). Our .cargo/config.toml sets +crt-static for all musl targets:

[target.'cfg(target_env = "musl")']
rustflags = ["-Ctarget-feature=+crt-static", ...]

We need ASAN builds to use -crt-static instead, without modifying the base config that all other builds use. We tried every override mechanism Cargo provides:

1. --config 'target...rustflags = ["-Ctarget-feature=-crt-static", ...]' (inline) — Cargo appends these to the existing array from config.toml, so rustc sees both +crt-static and -crt-static. Since +crt-static adds the feature and -crt-static removes it, you'd expect order to matter, but it doesn't: for some reason, +crt-static always wins when both are present, regardless of order.

2. --config file.toml — Same behavior, appends to arrays rather than replacing.

3. CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS — Also appends, same problem.

4. RUSTFLAGS env var — This is the only thing that works, because it fully replaces all config.toml rustflags. This is way too heavy-handed; it replaces flags for all targets and discards unrelated flags (frame pointers, symbol mangling, etc.) that we have to manually duplicate.

The root issue is that -Ctarget-feature doesn't use "last wins" semantics. When both +crt-static and -crt-static are present in the flags, + always wins. You can verify:

# -crt-static alone works:
rustc --target x86_64-unknown-linux-musl -Ctarget-feature=-crt-static --print cfg | grep crt
# (no output — feature removed)

# But +crt-static always wins when both present:
rustc --target x86_64-unknown-linux-musl -Ctarget-feature=+crt-static -Ctarget-feature=-crt-static --print cfg | grep crt
# target_feature="crt-static" ← still enabled!

Does anyone have any ideas on workarounds that we might use to fix this +/-crt-static thing? Is this a known issue?

1 post - 1 participant

Read full topic