Skip to content
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.

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

Numpy2 support fails when running with 32-bit windows #448

Closed
maffoo opened this issue Oct 3, 2024 · 5 comments · Fixed by #463
Closed

Numpy2 support fails when running with 32-bit windows #448

maffoo opened this issue Oct 3, 2024 · 5 comments · Fixed by #463

Comments

@maffoo
Copy link
Contributor

maffoo commented Oct 3, 2024

In #442 we identified a few issues when running against 32-bit windows. With numpy2 some tests fail because the dtype ELSIZE is incorrectly returning 0, while with numpy1 some examples were segfaulting. @adamreichold suggested that we disable using the library for 32-bit windows to unblock progress. This issue will track either fixing these issues or dropping support for 32-bit windows builds entirely.

@davidhewitt
Copy link
Member

I think you meant so say @itamarst made the suggestion, but yes 👍

@jakelishman
Copy link
Contributor

In our package, we're trying to eke out 32-bit Windows and Linux support in new releases until about February 2025, so I spent a bit of work time trying to help out here.

I tracked the failures down to some issues with the npyffi::types::npy_* type aliases for the static-sized types - things like npy_uint64 were defined in terms of c_ulong and friends, which aren't the same size on Windows 32-bit. Seems like those types just never appeared in FFI wrappers that were needed before now, so the problem didn't appear.

The ELSIZE returning zero was a symptom of the _PyArray_LegacyDescr::flags being defined as npy_uint64, which was typedef'd to c_ulong and so only actually using 32 bits on Windows x86. The extra zeros that were really the high bytes of flags then got interpreted as elsize. Everything else got all shifted too, so a bunch of zeros ended up being interpreted as pointers that needed to be dereferenced.

With #463 in place, I was able to run the full test suite on both archs of Windows locally without further issue.

@yookoala
Copy link

yookoala commented Oct 28, 2024

@davidhewitt: Sorry to be nudging. This merge fix the issue that actually blocks the installation of rust-numpy on Windows 32bit platform, which is needed for the Python 3.13 upgrade (see, for example, this CI workflow for this PR to fix this issue). It would be hugely helpful if you can make a patch release (e.g 0.22.1) with this merge.

P.S. Sorry, just discover you're on the same issue thread. You must have been working on this also 🤦🏻‍♂️. Thanks for your work.

@davidhewitt
Copy link
Member

Agreed; I hope to prep the patch release tonight, will probably then put it live tomorrow.

@davidhewitt
Copy link
Member

Release is now live

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants