GDB built on Ubuntu 20.04 is missing Python support

[lbmeng]

Ubuntu 20.04 does not ship Python 2, but GDB defaults to use Python 2.

The following patch can enable Python support with GDB on Ubuntu 20.04 by telling configure to use Python 3.

$ git diff
diff --git a/Makefile.in b/Makefile.in
index d3c4e92..6fab4aa 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -212,7 +212,8 @@ stamps/build-gdb-linux: $(GDB_SRCDIR)
                --disable-binutils \
                --disable-ld \
                --disable-gold \
-               --disable-gprof
+               --disable-gprof \
+               --with-python=/usr/bin/python3
        $(MAKE) -C $(notdir $@)
        $(MAKE) -C $(notdir $@) install
        mkdir -p $(dir $@) && touch $@
@@ -427,7 +428,8 @@ stamps/build-gdb-newlib: $(GDB_SRCDIR)
                --disable-binutils \
                --disable-ld \
                --disable-gold \
-               --disable-gprof
+               --disable-gprof \
+               --with-python=/usr/bin/python3
        $(MAKE) -C $(notdir $@)
        $(MAKE) -C $(notdir $@) install
        mkdir -p $(dir $@) && touch $@

[jim-wilson]

Ubuntu 20.04 does still have python2, it just doesn't install it by default. A web search will point to articles on how to install it and switch between python2 and python3. Or you can choose to use python3 as you have done. A better solution would be to add configure checkis to choose whether to use python2 or python3, but that is something that should be done upstream.

Curiously, my Ubuntu 20.04 system has /usr/bin/python pointing at python2, but I did a dist-upgrade from Ubuntu 18.04, so maybe this wasn't handled as intended by dist-upgrade.

[lbmeng]

The default fresh installation of Ubuntu 20.04 only ships python 3. This is unlike Ubuntu 16.04 or 18.04 which has python 2 as the default one.

Curiously, my Ubuntu 20.04 system has /usr/bin/python pointing at python2, but I did a dist-upgrade from Ubuntu 18.04, so maybe this wasn't handled as intended by dist-upgrade.

I think the dist-upgrade will keep the python alternates choice unchanged to the one where you upgraded from.

but that is something that should be done upstream.

Would you file an issue to the gdb upstream?

[jim-wilson]

I know that Ubuntu 20.04 does not install python2 by default. But it still has it. Maybe you can file a gdb bug upstream?

[sea212]

Another workaround - Before compiling, install python-is-python3: sudo apt install python-is-python3

[johnwinans]

I had the same problem on a Ubuntu 20.04 install. None of the above worked for me until I did this:
sudo apt-get install python-dev
I propose that python-dev (or python3-dev) be added to the list of prerequisites on the main README setup instructions.
After the python-dev install, I was able to rebuild from a clean checkout of:
commit b715e4f01b43efef487166f75d5d85d3c33fa7ef (HEAD -> master, tag: 2021.04.23, origin/master, origin/HEAD)
and without python-is-python3 installed.

[jim-wilson]

I have a patch on the jimw-gdb-python-fix branch that adds a simple configure check to test for the python binary name, trying python, python3, and python2 in that order, and then passing the binary name to gdb via --with-python=. Unfortunately, it isn't working on Ubuntu 20.04. It detects that we have python3 and configures gdb to use it, but the gdb/python/python-config.py script is failing, cannot import sysconfig from distutils. So I think a python3 package is missing. I don't know offhand how to test for that. This means we have to recommend installing a python package, but do we tell people to install python2 or install more of python3, or change which python is the default? Either way that may cause trouble for some people. There may not be a good solution here.

[johnwinans]

We need to locate the dev(el) bits rather than just the executables for python.
Looking around a bit I am wondering if some of the ideas here would work:

https://stackoverflow.com/questions/4848566/check-for-existence-of-python-dev-files-from-bash-script

These works on my Ubuntu 20.04 box and correctly identifies that python2-dev is present and that python3-dev is not (which is true on my system):

python2 -c 'from distutils.sysconfig import get_makefile_filename as m; from os.path import isfile; import sys ; sys.exit(not isfile(m()))'
python3 -c 'from distutils.sysconfig import get_makefile_filename as m; from os.path import isfile; import sys ; sys.exit(not isfile(m()))'

IMHO If we can't get a dynamic configuration to properly determine a 2 vs 3 then it seems like python3 might be a reasonable choice. Since the install guide for the toolchain already installs python3. It stands to reason that adding and using python3-dev(el) would be tolerable as well.