jyn

I don't mind if this doesn't work honestly, I just wish the error message were more helpful, rather than looking like a bug in the cc crate.

When would this be used? docs.rs and Crater both only build on one host platform.

> I'm currently exploring setting up a self-hosted instance of docs.rs for which we'd like to build on an arm64 machine. Additionally, I ran into blockers attempting to develop against...

In general it should be possible to run docs.rs on any host as long as it supports an x86 linux docker container. But we currently don't distinguish the host toolchain...

@OWissett can you confirm that switching to `libunwind14-dev` doesn't break the build script for `libunwind-sys` (https://docs.rs/crate/libunwind-sys/latest/source/build.rs)? If so, this change seems ok to me. I tried pinging the author of...

Ok, then I think we're blocked on the upstream bug.

This is an interesting problem. `sweep` *does* support cleaning that global target dir, but only if you're already in a project: ``` (bash@pop-os) ~/rust-community/cargo-sweep [18:42:07, ci] ; CARGO_TARGET_DIR=$CARGO_HOME/target cargo sweep...

@fenhl what does `rustc +stable-x86_64-unknown-linux-musl --version` output? If your toolchain already has an error, `cargo sweep` can't bypass it somehow, it needs to know the metadata hash of the version.

As a workaround, you can specify an individual toolchain: `cargo sweep --toolchains stable-x86_64-unknown-linux-gnu`

@fenhl cargo-sweep already says "failed to determine fingerprint for toolchain stable-x86_64-unknown-linux-musl" - how could that be improved?