dist: Ship more Windows import libs with the rust-mingw package of *-windows-gnullvm targets.

[ColinFinck]

This fixes building crates like https://crates.io/crates/blake3, which use cc and depend on additional Windows import libs.

The list of shipped Windows import libs now matches the rust-mingw package of the x86_64-pc-windows-gnu target.

Addendum to #147536

CC @mati865

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[bjorn3]

Correct me if I'm wrong, but if I understand this correctly, the list of import libraries is supposed to be exactly those that are necessary for the standard library. Once the standard library uses raw-dylib all import libraries would be removed from the rust-mingw package.

If you got a crate which uses cc, doesn't that mean you also have to have a Mingw C toolchain installed separately anyway? That toolchain should contain all import libraries C code may need.

[mati865]

Correct me if I'm wrong, but if I understand this correctly, the list of import libraries is supposed to be exactly those that are necessary for the standard library. Once the standard library uses raw-dylib all import libraries would be removed from the rust-mingw package.

This is correct, even for regular windows-gnu targets rust-mingw is not meant to provide full toolchain. Even less so when it comes to windows-gnullvm.

If you got a crate which uses cc, doesn't that mean you also have to have a Mingw C toolchain installed separately anyway? That toolchain should contain all import libraries C code may need.

BLAKE3 can build without C compiler, but in "degraded" mode - without optimised assembly. The problem here is usage of page_size crate, which depends on winapi. It's abandoned and shouldn't be used for years. This should be easy to solve in BLAKE3 repo.