-
Notifications
You must be signed in to change notification settings - Fork 125
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
master
fails on 32bit Windows in BP5 Serializer
#4105
Comments
Should |
Ugh. Making this stuff build and run cleanly on 32- and 64-bit was something I advocated for years ago, but couldn't get off the ground. (Doing it properly really requires saving output files from different platforms, making sure what's written on one is readable on another, etc. FFS does this, but we've not done it for ADIOS.) So, to the extent that we can tweak something and it gets us where we need to be, I'm completely supportive. I think the question is how far we go down the road from "it compiled once" through "it's in CI so we don't break it accidentally" to "we support and test 32/64 bit interoperability to the extent possible". WRT the specific question, yeah, Position is probably uint64_t, but given the pickiness of VS, making that change may require a bunch more casts somewhere. If you've go this setup and can sort out the compile issues, I'm happy to look at the PR, but the number of background code projects I've got on my plate is a little daunting at the moment, so tackling it myself might be slow. |
Generally, yes I would expect a file format (H5, BP4, BP5) to handle for me the concerns of how to encode a file so I can read it back between any system (little/big endian, 32bit to 64bit, platform specific sizes of ints and floats). Otherwise it is not a portable format. That said, at the current point (this issue), I am happy if things compile and in/out consistently on the same platform... This is what we deploy on downstream: openPMD-api deployment targets
openPMD-api deployment variants
|
Even coming up with a big-endian platform to do CI on is a challenge. Heterogeneity isn't what it used to be... |
(that said, I am personally not needing big endian support, luckily HPC has no such machine atm :D) |
Last BE machine I knew of was a Sparc-based machine at JAXA... Before it was activated I assumed that as a PowerPC machine Summit would be BE, but they put it in LE mode. Lots of BP5 code is untested for BE. |
Describe the bug
The current
master
does not build due to auint64_t
/size_t
mismatch on ILP32 platforms:To Reproduce
Build on Visual Studio / w/ MSVC in 32bit mode ("x86").
Expected behavior
Build on LP32, ILP32, LLP64 and LP64 platforms.
Desktop (please complete the following information):
Additional context
Building new wheels and this worked in the past: openPMD/openPMD-api#1554
You might wonder: what is wrong with you, why 32bit Windows?
You are right, this is to get an in with experimental physicists. In labs, some hardware has very weird control software and limited/old driver support, which only runs on 32bit Windows.
I am ok to ditch this eventually, but since it is easy to fix and keep general, we should do it.
The text was updated successfully, but these errors were encountered: