Bug 1897553
| Summary: | python-cypari2 fails to build with Python 3.10: Py_SIZE= needs to be replaced with Py_SET_SIZE | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomáš Hrnčiar <thrnciar> |
| Component: | python-cypari2 | Assignee: | Paulo Andrade <paulo.cesar.pereira.de.andrade> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | loganjerry, mhroncok, paulo.cesar.pereira.de.andrade, thrnciar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-16 16:27:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1890881 | ||
My Cython knowledge is rather thin. I can fix this just for Rawhide like this:
--- cypari2/convert.pyx.orig 2020-11-01 11:52:56.000000000 -0700
+++ cypari2/convert.pyx 2020-11-13 12:02:19.460676002 -0700
@@ -59,7 +59,7 @@ cdef extern from *:
ctypedef struct PyLongObject:
digit* ob_digit
- Py_ssize_t* Py_SIZE_PTR "&Py_SIZE"(object)
+ void Py_SET_SIZE(object, Py_ssize_t)
########################################################################
@@ -450,13 +450,11 @@ cdef PyLong_FromINT(GEN g):
if d:
sizedigits_final = i+1
- # Set correct size (use a pointer to hack around Cython's
- # non-support for lvalues).
- cdef Py_ssize_t* sizeptr = Py_SIZE_PTR(x)
+ # Set correct size
if signe(g) > 0:
- sizeptr[0] = sizedigits_final
+ Py_SET_SIZE(x, sizedigits_final)
else:
- sizeptr[0] = -sizedigits_final
+ Py_SET_SIZE(x, -sizedigits_final)
return x
It would be much better to have a patch that works across a range of cython and python versions, so that it can be submitted upstream. I need help with that. I see that the generated C file already has a macro __Pyx_SET_SIZE that does exactly what we want, but I don't know (a) if pyx code can be written somehow to refer to that or (b) what version of cython introduced it.
More succinct:
--- cypari2/convert.pyx.orig 2020-11-01 11:52:56.000000000 -0700
+++ cypari2/convert.pyx 2020-11-15 09:35:18.481436232 -0700
@@ -59,7 +59,7 @@ cdef extern from *:
ctypedef struct PyLongObject:
digit* ob_digit
- Py_ssize_t* Py_SIZE_PTR "&Py_SIZE"(object)
+ void __Pyx_SET_SIZE(object, Py_ssize_t)
########################################################################
@@ -450,13 +450,11 @@ cdef PyLong_FromINT(GEN g):
if d:
sizedigits_final = i+1
- # Set correct size (use a pointer to hack around Cython's
- # non-support for lvalues).
- cdef Py_ssize_t* sizeptr = Py_SIZE_PTR(x)
+ # Set correct size
if signe(g) > 0:
- sizeptr[0] = sizedigits_final
+ __Pyx_SET_SIZE(x, sizedigits_final)
else:
- sizeptr[0] = -sizedigits_final
+ __Pyx_SET_SIZE(x, -sizedigits_final)
return x
But that requires __Pyx_SET_SIZE, which a little research shows was added in Cython 0.29.20, released in June of this year. That is too recent to expect cypari2 upstream to want to commit to it. So how should this be handled for older versions of Cython?
I have never really seen a "we need to support old Cython" request before, but I suppose some IF might do, however I don't know from memory or quick googling how to cech the Cython version.
You should however be able to use:
IF PY_VERSION_HEX >= 0x031000a1:
...
(IF behaves like an #if.)
To use or define Py_SET_SIZE.
This is the recommended C code:
#if PY_VERSION_HEX < 0x030900A4
# define Py_SET_SIZE(obj, size) ((Py_SIZE(obj) = (size)), (void)0)
#endif
It might be transferable to Cython:
IF PY_VERSION_HEX < 0x030900A4:
DEF Py_SET_SIZE(obj, size) ((Py_SIZE(obj) = (size)), (void)0)
But I have never done a macro in DEF.
It looks like upstream may be willing to accept a Cython >= 0.29.20 restriction after all, since the latest sagemath release already requires Cython >= 0.29.21. I've added the patch from comment 2 and built in Rawhide. Upstream pull request: https://github.com/sagemath/cypari2/pull/103 JFYI The change was reverted in Python 3.10, because it caused too much trouble (the amount of affected Fedora packages was too big). This comment is mass posted in all relevant bugzillas. If you already worked upstream to fix the problem, you might want to let them know about the revert, but the new way of doing things also works. Sorry for the trouble and thanks again for the fix. https://github.com/python/cpython/commit/0e2ac21dd |
python-cypari2 fails to build with Python 3.10.0a2. cypari2/convert.c:3249:21: error: lvalue required as unary ‘&’ operand 3249 | __pyx_v_sizeptr = &Py_SIZE(((PyObject *)__pyx_v_x)); | ^ https://docs.python.org/3.10/whatsnew/changelog.html#id11 bpo-39573: Convert Py_REFCNT() and Py_SIZE() macros to static inline functions. They cannot be used as l-value anymore: use Py_SET_REFCNT() and Py_SET_SIZE() to set an object reference count and size. This change is backward incompatible on purpose, to prepare the C API for an opaque PyObject structure. https://bugs.python.org/issue39573 For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01763708-python-cypari2/ For all our attempts to build python-cypari2 with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-cypari2/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.