cargo clif build does not work on Windows

[luxalpa]

Setting up the tool like in the Readme, I am getting this error when running it as cargo clif build:

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -Cpanic=abort -Zpanic-abort-tests -Zcodegen-backend=C:\dev\cranelift\bin\rustc_codegen_cranelift.dll --sysroot C:\dev\cranelift --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 code: 1)
  --- stderr
  error: couldn't load codegen backend "C:\\dev\\cranelift\\bin\\rustc_codegen_cranelift.dll": LoadLibraryExW failed

The problem doesn't appear when using cargo-clif directly, and it appears on both the msvc and the gnu versions of the latest release.

[bjorn3]

C:\dev\cranelift\bin\rustc_codegen_cranelift.dll does exist, right? Unfortunately libloading (the crate rustc uses for dynamic linking) doesn't print the error returned by LoadLibraryExW and instead only prints a generic error message, making it hard for me to figure out what the issue is: nagisa/rust_libloading#133

[luxalpa]

Yes, the file does exist and it seems to be working when using cargo-clif.exe directly (including when using it from path, i.e. from some other directory). I'm only getting the error when using it via cargo clif command.

[bjorn3]

Could you try again with the latest master version? This now includes rust-lang/rust#119815 which should give a more useful error message.

[luxalpa]

Thanks, I've figured out the issue. Cargo uses a different environment based on the toolchain of the project in which it is being run. If it doesn't match the one that's been used to build rustc_codegen_cranelift, it won't find the right versions of the .dlls. Running

rustup run nightly-2024-01-21-x86_64-pc-windows-msvc cargo clif build

in the project folder works.

Ironically, due to this, the recent change to the error formating didn't actually yield any difference in output. It was still using the older nightly version and so it was still only displaying "LoadLibraryExW failed" without any useful error message, which had confused me at first.

[bjorn3]

That explains it. Does cargo clif -V show the nightly used by cg_clif or the default toolchain for your project?

[luxalpa]

It shows the default toolchain for the project (same as rustup shows active toolchain).

[bjorn3]

I can't reproduce that. No matter what I try cargo clif -V shows the toolchain with which cg_clif was built. I tried both in a directory with a different toolchain in rust-toolchain.toml and one with an override set using rustup override set. cargo resolves to the rustup wrapper, right? Not the cargo of a specific toolchain.

[bjorn3]

I think this is caused by some Windows specific behavior described in https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237

Could you try setting the RUSTUP_WINDOWS_PATH_ADD_BIN env var to 0?

[luxalpa]

Yes, setting that environment variable makes cargo clif build work.

[bjorn3]

Great! As I understand from the linked thread, that will be the default in the future.

[ChrisDenton]

This is now the default? https://github.com/rust-lang/rustup/blob/0c501d55c54031a992395078d535b6d2574dc693/src/toolchain/toolchain.rs#L168-L180

[bjorn3]

Rustup 1.27 was released just a couple of days before the default was flipped. So this will remain an issue until rustup 1.28 is released.