Build fails with cargo xwin and a build script

[PigeonF]

I am not sure if this is an issue with cargo-auditable, or with cargo-xwin, but since the backtrace suggests the culprit is cargo-auditable, I have opened an issue here.

I am on Linux, with cargo/rustc 1.83.0, cargo-auditable 0.6.6, and cargo-xwin 0.18.2.

Trying to run cargo auditable xwin build --target x86_64-pc-windows-msvc fails with

error: linker flavor `lld-link` is incompatible with the current target

thread 'main' panicked at cargo-auditable/src/collect_audit_data.rs:79:9:
cargo metadata failure: error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/home/pigeonf/.local/share/rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names -C linker-flavor=lld-link -Lnative=/home/pigeonf/.cache/cargo-xwin/xwin/crt/lib/x86_64 -Lnative=/home/pigeonf/.cache/cargo-xwin/xwin/sdk/lib/um/x86_64 -Lnative=/home/pigeonf/.cache/cargo-xwin/xwin/sdk/lib/ucrt/x86_64 --target x86_64-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit status: 1)
  --- stdout
  ___
  lib___.rlib
  lib___.so
  lib___.so
  lib___.a
  lib___.so
  /home/pigeonf/.local/share/rustup/toolchains/stable-x86_64-unknown-linux-gnu
  off
  packed
  unpacked
  ___
  debug_assertions
  panic="unwind"
  proc_macro
  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_has_atomic="16"
  target_has_atomic="32"
  target_has_atomic="64"
  target_has_atomic="8"
  target_has_atomic="ptr"
  target_os="linux"
  target_pointer_width="64"
  target_vendor="unknown"
  unix

  --- stderr
  error: linker flavor `lld-link` is incompatible with the current target
    |
    = note: compatible flavors are: gnu, gnu-lld, gnu-cc, gnu-lld-cc, gcc, ld, ld.lld

  error: aborting due to 1 previous error


stack backtrace:
   0:     0x55f60f65764a - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h304520fd6a30aa07
   1:     0x55f60f67bdeb - core::fmt::write::hf5713710ce10ff22
   2:     0x55f60f654c33 - std::io::Write::write_fmt::hda708db57927dacf
   3:     0x55f60f658f92 - std::panicking::default_hook::{{closure}}::he1ad87607d0c11c5
   4:     0x55f60f658bfe - std::panicking::default_hook::h81c8cd2e7c59ee33
   5:     0x55f60f65981f - std::panicking::rust_panic_with_hook::had2118629c312a4a
   6:     0x55f60f659507 - std::panicking::begin_panic_handler::{{closure}}::h7fa5985d111bafa2
   7:     0x55f60f657b29 - std::sys::backtrace::__rust_end_short_backtrace::h704d151dbefa09c5
   8:     0x55f60f659194 - rust_begin_unwind
   9:     0x55f60f5ce943 - core::panicking::panic_fmt::h3eea515d05f7a35e
  10:     0x55f60f6003c1 - cargo_auditable::collect_audit_data::compressed_dependency_list::hd31a25603145c6fa
  11:     0x55f60f5f5b04 - cargo_auditable::rustc_wrapper::main::h3f74493c52c04d0f
  12:     0x55f60f5fa93b - cargo_auditable::main::hb7812aa69da0b099
  13:     0x55f60f609083 - std::sys::backtrace::__rust_begin_short_backtrace::hc0e28afdd3f4133f
  14:     0x55f60f60a959 - std::rt::lang_start::{{closure}}::had016ce6569b8f7b
  15:     0x55f60f651510 - std::rt::lang_start_internal::h4d90db0530245041
  16:     0x55f60f5faa05 - main
  17:     0x7fdab583127e - __libc_start_call_main
  18:     0x7fdab5831339 - __libc_start_main_alias_2
  19:     0x55f60f5cf0be - _start
  20:                0x0 - <unknown>
error: could not compile `foo` (build script)

Caused by:
  process didn't exit successfully: `/home/pigeonf/.local/share/cargo/bin/cargo-auditable /home/pigeonf/.local/share/rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --crate-name build_script_build --edition=2021 build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=262 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --check-cfg 'cfg(docsrs)' --check-cfg 'cfg(feature, values())' -C metadata=4a85d0794e518f95 -C extra-filename=-4a85d0794e518f95 --out-dir /tmp/tmp.zoyfG9Jc3O/target/debug/build/foo-4a85d0794e518f95 -C incremental=/tmp/tmp.zoyfG9Jc3O/target/debug/incremental -L dependency=/tmp/tmp.zoyfG9Jc3O/target/debug/deps` (exit status: 101)

I can only reproduce this when using a build script:

1. Create a new cargo project

cd $(mktemp -d)
cargo init --name foo

2. Verify that the command works without a build script

cargo auditable xwin build --target x86_64-pc-windows-msvc

3. Create a dummy build script and observe the command fail

$ echo "fn main() {}" > build.rs
$ cargo auditable xwin build --target x86_64-pc-windows-msvc
...
--- stderr
error: linker flavor `lld-link` is incompatible with the current target
  |
  = note: compatible flavors are: gnu, gnu-lld, gnu-cc, gnu-lld-cc, gcc, ld, ld.lld

error: aborting due to 1 previous error

I believe this issue resides with cargo-auditable interacting (or even just buildling?) the build script, but being unhappy with the linker set by cargo-xwin? I know nothing of either internals, but I found a weird workaround: running cargo-auditable once without cargo-xwin ensures that subsequent invocations of the full command work, at least until the build script is modified again.

1. In the same project as above (with the build script), run cargo-auditable without xwin

cargo clean
cargo auditable check --target x86_64-pc-windows-msvc

2. Build with the full command again

cargo auditable xwin build --target x86_64-pc-windows-msvc # Works!
touch src/main.rs
cargo auditable xwin build --target x86_64-pc-windows-msvc # Works still!

3. After modifying the build script, the full command fails again

$ touch build.rs
$ cargo auditable xwin build  --target x86_64-pc-windows-msvc
...
--- stderr
error: linker flavor `lld-link` is incompatible with the current target
  |
  = note: compatible flavors are: gnu, gnu-lld, gnu-cc, gnu-lld-cc, gcc, ld, ld.lld

error: aborting due to 1 previous error

I have confirmed that when using the workaround the created binary is actually runnable on windows, and cargo audit bin finds the auditable metadata in the binary, so it seems that the workaround actually works, and not just silently fails somehow.

[Shnatsel]

Well, that looks like an intersection of cargo xwin, cargo auditable and Cargo's own caching. That's going to be fun to debug, I can already tell.

Could you also post the output of cargo +nightly config -Z unstable-options get in the sample project? I want to see if there are any local configuration values possibly affecting the build.

[PigeonF]

$ cargo +nightly config -Z unstable-options get
doc.browser = ["lemonade", "open"]
registries.kellnr.index = "sparse+http://kellnr.internal/api/v1/crates/"
# The following environment variables may affect the loaded values.
# CARGO_HOME=/home/pigeonf/.local/share/cargo

So nothing I think that is applicable