Created attachment 597608 [details, diff] patch to compile with Python3.8 The struct PyTypeObject has changed in Python3.8 The attached patch takes this into account. This version has to be enhanced with #if constructs to make it work for all versions of Python
is this patch upstream? whats the commit hash? and what exactly changed in the struct? is a change like this backwards compatible with <py3.8?
(In reply to Jason Zaman from comment #1) > is this patch upstream? whats the commit hash? and what exactly changed in > the struct? is a change like this backwards compatible with <py3.8? Comparing /usr/include/python3.8/cpython/object.h with /usr/include/python3.7m/object.h there is a change from printfunc tp_print; # Python < 3.8 to Py_ssize_t tp_vectorcall_offset; # Python3.8 An object of pointer to function can be initialized by nullptr as well as by 0, but an object of type Py_ssize_t cannot be initialized by nullptr. Therefore it is safe to replace the initial value 'nullptr' with 0. I have checked this with gcc-9.2.0 (old versions of gcc don't even know about 'nullptr') So, I regard this patch as safe even for older versions of Python. BTW, this change is necessary for quite a few packages when switching to Python3.8 My whole system is free of Python3.x with x < 8, now, but it has been a lot of work.
(In reply to Helmut Jarausch from comment #2) > (In reply to Jason Zaman from comment #1) > > is this patch upstream? whats the commit hash? and what exactly changed in > > the struct? is a change like this backwards compatible with <py3.8? > > Comparing > /usr/include/python3.8/cpython/object.h > > with > > /usr/include/python3.7m/object.h > > there is a change > > from > printfunc tp_print; # Python < 3.8 > to > Py_ssize_t tp_vectorcall_offset; # Python3.8 > > An object of pointer to function can be initialized by nullptr as well as by > 0, > but an object of type Py_ssize_t cannot be initialized by nullptr. > > Therefore it is safe to replace the initial value 'nullptr' with 0. okay this makes sense yeah. > I have checked this with gcc-9.2.0 huh, but CUDA requires gcc-8 still and doesnt support gcc-9 yet, so it'll be built with gcc-8 even if gcc-9 is your main compiler in gcc-config. Or are you not using CUDA? > (old versions of gcc don't even know about 'nullptr') > > So, I regard this patch as safe even for older versions of Python. > > BTW, this change is necessary for quite a few packages when switching to > Python3.8 > My whole system is free of Python3.x with x < 8, now, but it has been a lot > of work. Fair enough, I'll give it a shot on my stable system (so python3_6 still) and if it works i'll apply it in rc1. Do you want to file a PR upstream too? or should I just take care of it?
I can't use CUDA here, since I don't have an NVIDIA graphics card. Please initiate a pull request upstreams. Thanks, Helmut
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf9a3c5ff72cb0d2998a739cdfe83cc5213fa8a0 commit cf9a3c5ff72cb0d2998a739cdfe83cc5213fa8a0 Author: Jason Zaman <perfinion@gentoo.org> AuthorDate: 2019-12-23 02:32:20 +0000 Commit: Jason Zaman <perfinion@gentoo.org> CommitDate: 2019-12-23 02:32:52 +0000 sci-libs/tensorflow: bump 2.1.0_rc1 Bug: https://bugs.gentoo.org/701342 Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Jason Zaman <perfinion@gentoo.org> sci-libs/tensorflow/Manifest | 2 + .../tensorflow-2.1.0-python3.8-pywrap_tensor.patch | 11 + sci-libs/tensorflow/tensorflow-2.1.0_rc1.ebuild | 372 +++++++++++++++++++++ 3 files changed, 385 insertions(+)
Most of this patch was already in TF-2.1 in this commit: https://github.com/tensorflow/tensorflow/commit/3a48a5c1541daa1fc3f49b9dbe0da247e7cd90f3 Only one part was missing so I patched that part. A bunch of the deps dont have python3_8 added yet so I couldnt add python3_8 to PYTHON_COMPAT yet. Have you overridden PYTHON_COMPAT locally for the deps and tested everything works? the keras deps almost certainly work, grpc would be my biggest question, that occasionally has issues. Keeping this bug open a while longer until deps are sorted too.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81d6d00f81b49112fcca4b91f2121878db355724 commit 81d6d00f81b49112fcca4b91f2121878db355724 Author: Jason Zaman <perfinion@gentoo.org> AuthorDate: 2020-01-25 14:21:01 +0000 Commit: Jason Zaman <perfinion@gentoo.org> CommitDate: 2020-01-26 05:35:17 +0000 sci-libs/tensorflow: bump 2.1.0 Closes: https://bugs.gentoo.org/701334 Closes: https://bugs.gentoo.org/704490 Closes: https://bugs.gentoo.org/701342 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Jason Zaman <perfinion@gentoo.org> sci-libs/tensorflow/Manifest | 3 ++- .../files/tensorflow-2.1.0-external_libs.patch | 26 ---------------------- .../tensorflow-2.1.0-python3.8-pywrap_tensor.patch | 11 --------- ...ow-2.1.0_rc2.ebuild => tensorflow-2.1.0.ebuild} | 14 +++++------- 4 files changed, 7 insertions(+), 47 deletions(-)
