rust-lang / rustc_codegen_cranelift

Cranelift based backend for rustc
Apache License 2.0
1.52k stars 94 forks source link

`cargo clif build` does not work on Windows #1447

Open luxalpa opened 5 months ago

luxalpa commented 5 months ago

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 commented 5 months ago

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: https://github.com/nagisa/rust_libloading/issues/133

luxalpa commented 5 months ago

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 commented 5 months ago

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

luxalpa commented 5 months ago

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 commented 5 months ago

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

luxalpa commented 5 months ago

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

bjorn3 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

bjorn3 commented 5 months ago

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

ChrisDenton commented 3 months ago

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

bjorn3 commented 3 months ago

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.