Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ColinFinck wants to merge 1 commit into from
Closed

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 28 additions & 2 deletions src/bootstrap/src/core/build_steps/dist.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Copy Markdown
Member

@bjorn3 bjorn3 Jan 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@mati865 mati865 Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@ColinFinck ColinFinck Feb 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

"libadvapi32.a",
"libbcrypt.a",
"libcomctl32.a",
"libcomdlg32.a",
"libcredui.a",
"libcrypt32.a",
"libdbghelp.a",
"libgdi32.a",
"libimagehlp.a",
"libiphlpapi.a",
"libkernel32.a",
"libuser32.a",
"libmsimg32.a",
"libmsvcrt.a",
"libntdll.a",
"libodbc32.a",
"libole32.a",
"liboleaut32.a",
"libopengl32.a",
"libpsapi.a",
"librpcrt4.a",
"libsecur32.a",
"libsetupapi.a",
"libshell32.a",
"libsynchronization.a",
"libuser32.a",
"libuserenv.a",
"libuuid.a",
"libwinhttp.a",
"libwinmm.a",
"libwinspool.a",
"libws2_32.a",
"libdbghelp.a",
"libwsock32.a",
];

//Find mingw artifacts we want to bundle
Expand Down
Loading