You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
windows-sys generated WinAPI bindings break ARM platforms #112265
In #110152 the WinAPI definitions have been replaced by windows-bindgen generated bindings. However, the win32metadata project does not generate metadata for ARM32-specific items, hence the generated bindings lack a few types like CONTEXT and WSADATA on this platform. It effectively breaks thumbv7a-*-windows-* for Rust.
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in the prelude, copied from before the changes.
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib.
Iirc, the Nt functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
Iirc, the Nt functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
I think you are correct. I can reproduce the link errors with toolchain nightly-2023-05-06. Let me file another issue after I pinpoint the underlying problem.
Activity
ChrisDenton commentedon Jun 4, 2023
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in the prelude, copied from before the changes.
bdbai commentedon Jun 4, 2023
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib.

ChrisDenton commentedon Jun 4, 2023
Iirc, the
Ntfunctions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.bdbai commentedon Jun 4, 2023
I think you are correct. I can reproduce the link errors with toolchain
nightly-2023-05-06. Let me file another issue after I pinpoint the underlying problem.ChrisDenton commentedon Jun 4, 2023
Oh wait, as staticlib? You currently need to make sure to link all the libraries it depends on. You can get them using
--print native-static-libs.bdbai commentedon Jun 4, 2023
This will fail Windows App Cert Kit tests.
ChrisDenton commentedon Jun 4, 2023
In that case I'm surprised that lazy loading worked.
apiraino commentedon Jun 6, 2023
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-low
Rollup merge of rust-lang#112484 - bdbai:fix/uwpntdll, r=ChrisDenton
Rollup merge of rust-lang#112527 - bdbai:fix/winarm32, r=ChrisDenton
Rollup merge of #112484 - bdbai:fix/uwpntdll, r=ChrisDenton