`x86_64-unknown-linux-musl` is the default target used by `cargo fuzz run` on my `x86_64-unknown-linux-gnu` host

[tyilo]

This doesn't work because musl-g++ is not installed.

Using cargo fuzz run --target x86_64-unknown-linux-gnu ... works.

I'm using Arch Linux and have the following targets installed:

$ rustup target list --installed
aarch64-linux-android
aarch64-unknown-linux-gnu
armv7-linux-androideabi
armv7-unknown-linux-gnueabihf
i686-linux-android
i686-pc-windows-gnu
i686-unknown-linux-gnu
thumbv7neon-linux-androideabi
x86_64-linux-android
x86_64-pc-windows-gnu
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl

Version of cargo-fuzz and rustc:

$ cargo +nightly fuzz --version
cargo-fuzz 0.12.0

$ rustc +nightly -vV
rustc 1.86.0-nightly (a567209da 2025-02-13)
binary: rustc
commit-hash: a567209daab72b7ea59eac533278064396bb0534
commit-date: 2025-02-13
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7

[saethlin]

It sounds like you have a

[build]
target = "x86_64-unknown-linux-musl"

Set in one of the locations you can put a Cargo config: https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

For sure on my x86_64-unknown-linux-gnu setups, the musl target is not used. Even if it is installed.

[tyilo]

It sounds like you have a

[build]
target = "x86_64-unknown-linux-musl"

Set in one of the locations you can put a Cargo config: https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

I don't which is the weird thing. Furthermore I can see that the built binary for my library links to libc.so.6 and rustc --print=cfg also prints that the target_env is gnu:

$ cargo +nightly -Z unstable-options rustc --print=cfg
debug_assertions
fmt_debug="full"
overflow_checks
panic="unwind"
relocation_model="pic"
target_abi=""
target_arch="x86_64"
target_endian="little"
target_env="gnu"
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_feature="x87"
target_has_atomic
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="64"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="64"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_os="linux"
target_pointer_width="64"
target_thread_local
target_vendor="unknown"
ub_checks
unix

[tyilo]

I think I found the cause of the problem.

If I install cargo-fuzz with cargo install cargo-fuzz everything works.

However, I had installed cargo-fuzz with cargo binstall cargo-fuzz which installs the musl version from https://github.com/rust-fuzz/cargo-fuzz/releases/tag/0.12.0

I still think that in this case that cargo-fuzz should use the gnu target by default.

[saethlin]

The relevant code is here:

cargo-fuzz/src/utils.rs

Lines 1 to 4 in 95f7737

	/// The default target to pass to cargo, to workaround issue #11.
	pub fn default_target() -> &'static str {
	current_platform::CURRENT_PLATFORM
	}

current_platform documents that

Platform information is resolved at compile time, based on the platform for which your code is compiled. It incurs zero runtime cost.

The documentation seems pretty confused about whether it is for the target you're running on vs the target that the code was compiled for. Based on the implementation, it's quite clearly the target that the code was compiled for.

You are expecting cargo-fuzz to be using the approach in https://crates.io/crates/rustc-host. But I can't tell if cargo-fuzz switching to using the local rustc toolchain host instead of the target cargo-fuzz was built for will just result in someone filing the inverse ticket that you are.

[tyilo]

If you don't want to change the default target to the host target, then I think either of these should be done:

• Provide a cargo-fuzz-*-x86_64-unknown-linux-gnu.tar.gz download for each release
• Don't provide a cargo-fuzz-*-x86_64-unknown-linux-musl.tar.gz download for each release

If we don't provide the gnu version to the user, we shouldn't just let them download a "non-functioning" musl version, but force linux users to always built their own using cargo install.

[saethlin]

Oh jeez I didn't realize this project was uploading musl releases 🤦
That's just an oversight, nobody realized what that does. I'm a bit surprised nobody has reported this problem before.

[kaleidawave]

Is there are a reason why the GitHub releases do not include a non musl cargo-fuzz tool? Should not be too difficult to add