Open luxalpa opened 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
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.
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.
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.
That explains it. Does cargo clif -V
show the nightly used by cg_clif or the default toolchain for your project?
It shows the default toolchain for the project (same as rustup show
s active toolchain).
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.
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?
Yes, setting that environment variable makes cargo clif build
work.
Great! As I understand from the linked thread, that will be the default in the future.
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.
Setting up the tool like in the Readme, I am getting this error when running it as
cargo clif build
: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.