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.