On openSUSE tumbleweed I build with --with-python=python3, and python3 has recently been bumped to: ... $ /usr/bin/python3 --version Python 3.10.5 ... Consequently, I run into build failures, due to (reproducing outside build): ... $ python3.10 ./gdb/python/python-config.py --includes ./gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives from distutils import sysconfig /data/vries/gdb_versions/devel/binutils-gdb.git/./gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead from distutils import sysconfig -I/usr/include/python3.10 -I/usr/include/python3.10 ... The message suggests using module sysconfig, but there's no suppport for get_python_inc in there. The PEP also doesn't list a solution. Also setuptools is mentioned, but that doesn't seem to provide a get_python_inc replacement either. Looking in python3-config, it's no longer a python script, but a shell script, so we can't find an example there either. For now working around it by using --with-python=/usr/bin/python3.8.
Why do we ship our own python-config.py? We could maybe rely on the python-config scripts shipped with Python installations. I guess that python-config scripts were maybe not always there in the past? We would append `-config` to the python executable. Since you passed --with-python=python3, it means python3 is in your PATH, so python3-config should also exist in your PATH. My guess is that since python-config scripts are now shell scripts, they can be executed on the build machine even cross-compiling. So maybe it would simplify the case described here: https://sourceware.org/gdb/wiki/CrossCompilingWithPythonSupport Not sure.
(In reply to Simon Marchi from comment #1) > Why do we ship our own python-config.py? Here ( https://sourceware.org/pipermail/gdb-patches/2010-May/074836.html ) is mentioned: ... python-config is a python script so it won't work when build != host. ... > We could maybe rely on the > python-config scripts shipped with Python installations. I'll give that a try. > I guess that > python-config scripts were maybe not always there in the past? > AFAICT, the python-config shell script was introduced starting 3.4. From looking at the cpython.git sources, the python-config python script appeared in 2.7, but looking at the original commit of gdb/python/python-config.py is mentions a copy from 2.6.5, so perhaps I'm missing something. > We would append `-config` to the python executable. Since you passed > --with-python=python3, it means python3 is in your PATH, so python3-config > should also exist in your PATH. > FWIW, I need to install python3-devel to get python3-config, in addition to the python3 package, but that's not a problem of course. I need to install lots of -devel packages to be able to build gdb. > My guess is that since python-config scripts are now shell scripts, they can > be executed on the build machine even cross-compiling. So maybe it would > simplify the case described here: > > https://sourceware.org/gdb/wiki/CrossCompilingWithPythonSupport > > Not sure. AFAICT, that was exactly the purpose of moving to a shell script.
(In reply to Tom de Vries from comment #2) > > My guess is that since python-config scripts are now shell scripts, they can > > be executed on the build machine even cross-compiling. So maybe it would > > simplify the case described here: > > > > https://sourceware.org/gdb/wiki/CrossCompilingWithPythonSupport > > > > Not sure. > > AFAICT, that was exactly the purpose of moving to a shell script. See https://bugs.python.org/issue16235 .
Created attachment 14189 [details] Demonstrator patch This (configure-only, leaving configure.ac alone for now) patch fixes the build for me. I guess this will break pre 3.4 python setup. So perhaps, it's an idea to first try python's python-config, and if that doesn't work, fall back on gdb's. Also note the added --embed, which is required starting 3.8, but unsupported before, we'll probably have to do trial and error there as well.
Kevin, I saw you submit a patch for python 3.11 support ( https://sourceware.org/pipermail/gdb-patches/2022-June/190460.html ). Did you also run into this build issue?
(In reply to Tom de Vries from comment #5) > Kevin, I saw you submit a patch for python 3.11 support ( > https://sourceware.org/pipermail/gdb-patches/2022-June/190460.html ). > > Did you also run into this build issue? I haven't yet seen the build issues that you mention here.
> FWIW, I need to install python3-devel to get python3-config, in addition to the python3 package, but that's not a problem of course. I need to install lots of -devel packages to be able to build gdb. I would expect that you need python3-devel anyway, since that's probably what provides Python.h? > I guess this will break pre 3.4 python setup. > > So perhaps, it's an idea to first try python's python-config, and if that doesn't work, fall back on gdb's. I don't think it's a big deal to break pre-Python 3.4. We currently support Python pre-3.4, just because there wasn't a specific reason not to. It didn't require significantly more work to do so. This could be a good reason to start requiring Python >= 3.4, if doing so makes things significantly simpler.
(In reply to Simon Marchi from comment #7) > > FWIW, I need to install python3-devel to get python3-config, in addition to the python3 package, but that's not a problem of course. I need to install lots of -devel packages to be able to build gdb. > > I would expect that you need python3-devel anyway, since that's probably > what provides Python.h? > True. > > I guess this will break pre 3.4 python setup. > > > > So perhaps, it's an idea to first try python's python-config, and if that doesn't work, fall back on gdb's. > > I don't think it's a big deal to break pre-Python 3.4. We currently support > Python pre-3.4, just because there wasn't a specific reason not to. It > didn't require significantly more work to do so. This could be a good > reason to start requiring Python >= 3.4, if doing so makes things > significantly simpler. Crossref https://sourceware.org/pipermail/gdb-patches/2022-January/184908.html .
(In reply to Kevin Buettner from comment #6) > (In reply to Tom de Vries from comment #5) > > Kevin, I saw you submit a patch for python 3.11 support ( > > https://sourceware.org/pipermail/gdb-patches/2022-June/190460.html ). > > > > Did you also run into this build issue? > > I haven't yet seen the build issues that you mention here. I've now tried with 3.11, and seen the same deprecation warning, but indeed not this build problem. After trying again with 3.10, still the same deprecation warning, but now this build also succeeds. Hmm... Anyway, this is going to hit us with python 3.12, updating $subject.
Looks like this was fixed in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=be2057b902e834bba6fe7d3ded16177ec5624f3b .