Does not build out of the box on `x86_64-pc-windows-gnu` (dlltool.exe: program not found)

[ColinFinck]

Attempting to build latest getrandom on a pristine Windows installation with the x86_64-pc-windows-gnu toolchain results in an error calling dlltool 'dlltool.exe': program not found failure. This is a known Rust bug of the -gnu targets when using raw-dylib (see rust-lang/rust#103939): The -gnu targets add a call to dlltool but don't ship dlltool.

Using the new -gnullvm target is no alternative either, because it currently lacks even more components: rust-lang/rust#146634.
I cannot use the -msvc targets, because I need a freely redistributable toolchain. I also cannot install the missing dlltool.exe. To sum it up: getrandom needs to work for me on a pristine unmodified x86_64-pc-windows-gnu toolchain.

This was no problem until the merge of #627.

I see several options how to solve this problem:

1. Reverting Use "raw-dylib" for non-win7 Windows Targets #627 and using windows-targets again.
2. Retrieving the address of ProcessPrng at runtime using LoadLibraryW and GetProcAddress (can be put in a OnceLock to not do that on every call).
3. Adding a feature to use RtlGenRandom instead.

As a quick fix, I'll go with option 3 for now. What do you think could be a long-term solution?

CC @josephlr @newpavlov

[ColinFinck]

This is how I fixed it for me now: osdyne@23f5f0d
Currently, I'm only using getrandom as a dependency of tempfile, so the quality of the generated random numbers is negligible. Your mileage may vary.

If this is a fix you would accept, I could open a PR.

[newpavlov]

Shouldn't it be fixed on the language level? The same linking approach based on kind = "raw-dylib" is also used by std, so just changing getrandom would not help you.

[newpavlov]

You can enable the legacy backend using the getrandom_windows_legacy configuration flag (we use it in our build.rs).

[ColinFinck]

Thanks for your quick responses!

You're right that more and more crates are adopting raw-dylib (including std and windows-sys), so just working around that in getrandom may work now but not for long.
Anyway, thank you for coming up with #724. That should do the job for now 👍

[3052]

for anyone confused, that means doing this:

$env:RUSTFLAGS="--cfg=getrandom_windows_legacy"

another terrible option is making dlltool.bat:

zig dlltool %*

then:

$env:RUSTFLAGS = '-C dlltool=dlltool.bat'

[newpavlov]

The windows_legacy opt-in backend is merged and will be released in v0.3.4. The getrandom_windows_legacy configuration flag will be removed in favor of it.

[josephlr]

windows_legacy is the correct solution to this for users which cannot use kind = "raw-dylib". Thanks @newpavlov for fixing this in #724. Now users can do:

$env:RUSTFLAGS='getrandom_backend="windows_legacy"'

and things should be fine.

The long-term answer is folks to have properly setup toolchains when building Rust. That should either involve fixing rust-lang/rust#103939 or properly installing dlltool.

[mati865]

Attempting to build latest getrandom on a pristine Windows installation with the x86_64-pc-windows-gnu toolchain results in an error calling dlltool 'dlltool.exe': program not found failure. This is a known Rust bug of the -gnu targets when using raw-dylib (see rust-lang/rust#103939): The -gnu targets add a call to dlltool but don't ship dlltool.

This is false. 103939 is about cross-compilation from Windows to different Windows arch not working. It works (or at least used to work) when building natively because dlltool is shipped: https://github.com/rust-lang/rust/blob/0b278a539440be291466ea463a9b6310eaf4d7bb/src/bootstrap/src/core/build_steps/dist.rs#L213

[3052]

@mati865 you are wrong. using this:

https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe

with these options

default host triple: x86_64-pc-windows-gnu
default toolchain: stable
profile: default

if I search C:\Users\Steven\.cargo, I only see these

bin\cargo-clippy.exe
bin\cargo-fmt.exe
bin\cargo-miri.exe
bin\cargo.exe
bin\clippy-driver.exe
bin\rls.exe
bin\rust-analyzer.exe
bin\rust-gdb.exe
bin\rust-gdbgui.exe
bin\rust-lldb.exe
bin\rustc.exe
bin\rustdoc.exe
bin\rustfmt.exe
bin\rustup.exe

[mati865]

@3052 rustc doesn't put its libs into ~/.cargo/bin (that would be bad). Look inside ~/.rustup/toolchains/<name>, I think it should be inside ~/.rustup/toolchains/stable-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin (typing from memory so it could be slightly off). It likely requires rust-mingw component to be installed, which is the default.