-
-
Notifications
You must be signed in to change notification settings - Fork 90
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
Having trouble building python-zstandard for pypy2 on windows #61
Comments
There isn't explicit test coverage of python-zstandard on PyPy on Windows in CI. However, there is test coverage of 32-bit Windows on CPython 2.7. An example build for that is at https://ci.appveyor.com/project/indygreg/python-zstandard/builds/20028053/job/5xa633pei1siq87s. If we compare the failing command invocation for compiling good:
The other differences boil down to include paths for CPython versus PyPy. Since the compilation is complaining about missing I reckon this can be fixed by adding a |
In all these cases, we are comparing a Py_ssize_t (from Python obviously) with a size_t in zstd. The Py_ssize_t type is signed. But in these cases, the value refers to the length of a Py_buffer. The length of a Py_buffer can never be negative. And the size of Py_ssize_t must be the same as size_t. So it follows that casting a Py_buffer to size_t should be safe. This avoids the use of ssize_t in our code. And this should hopefully unblock building the extension with PyPy on Windows. Fixes #61.
I can't guarantee things are fixed or will stay fixed since there isn't CI coverage of PyPy on Windows, but I think the upcoming 0.10.2 release will fix this You should definitely run the tests to make sure things fail. And you may want to file an issue to track running PyPy on Windows in this project's CI. It looks to be possible with AppVeyor... |
In all these cases, we are comparing a Py_ssize_t (from Python obviously) with a size_t in zstd. The Py_ssize_t type is signed. But in these cases, the value refers to the length of a Py_buffer. The length of a Py_buffer can never be negative. And the size of Py_ssize_t must be the same as size_t. So it follows that casting a Py_buffer to size_t should be safe. This avoids the use of ssize_t in our code. And this should hopefully unblock building the extension with PyPy on Windows. Fixes #61.
Recently i was unsuccessfully trying to build module for pypy2-v6.0.0-win32 on windows 10 x64:
Please, help me to understand what`s went wrong and how to fix it.
The text was updated successfully, but these errors were encountered: