dist: Ship more Windows import libs with the rust-mingw package of *-windows-gnullvm targets.#151108
dist: Ship more Windows import libs with the rust-mingw package of *-windows-gnullvm targets.#151108ColinFinck wants to merge 1 commit intorust-lang:mainfrom
rust-mingw package of *-windows-gnullvm targets.#151108Conversation
…`*-windows-gnullvm` targets. 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.
rustbot
added
S-waiting-on-review
|
rustbot has assigned @Mark-Simulacrum. Use |
| @@ -318,12 +318,38 @@ fn make_win_llvm_dist(plat_root: &Path, target: TargetSelection, builder: &Build | |||
| "libmingwex.a", | |||
| "libmsvcrt.a", | |||
| // Windows import libs, remove them once std transitions to raw-dylib | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Thank you for the explanations! I've recently opened a few PRs in dependency crates to get them to adopt windows-sys 0.61, which makes use of raw-dylib. Once all of these PRs go through and I update my Cargo.toml, we should be good to go without shipping additional import libs. Closing this PR.
|
r? @mati865 (or feel free to suggest someone else with more familiarity with this list) |
|
I'll mark this as waiting on the author given the review comments in #151108 (review) @rustbot author |
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
rustbot
removed
the
S-waiting-on-author
5 participants
This fixes building crates like https://crates.io/crates/blake3, which use
ccand depend on additional Windows import libs.The list of shipped Windows import libs now matches the
rust-mingwpackage of thex86_64-pc-windows-gnutarget.Addendum to #147536
CC @mati865