0

I'm trying to build the latest gdb 10.1 from source.

[My reason for wanting to do it is that I'm trying to debug a program that links to a custom build of Python 2.7.18, and my system gdb was linked to the build of Python 2.7.5 in my /lib64 directory and doesn't work with the newer version].

Having read through the README file, I have configured using:

../gdb-10.1/configure --with-python=<path to my 2.7.18 installation> --prefix=<path to where I want the new gdb to go>

...and then run

make all install

...per the instructions. However, every attempt to build then fails in a slew of error messages of the form:

python/py-arch.o: In function `gdbarch_to_arch_object(gdbarch*)':
.../build/gdb/../../../gdb-10.1/gdb/python/py-arch.c:86: undefined reference to `_Py_RefTotal'
python/py-arch.o: In function `gdbpy_ref_policy<_object>::decref(_object*)':
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_NegativeRefcount'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_Dealloc'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_NegativeRefcount'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_Dealloc'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_Dealloc'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_NegativeRefcount'

On inspecting the output of the configure step, and the Makefile itself, I can find no reference at all to the Python installation that I specified at configure time (and which I've also placed at the head of my LD_LIBRARY_PATH to ensure that the compiler and linker can find it when building).

What am I missing here?

Darren Smith
  • 2,261
  • 16
  • 16
Eos Pengwern
  • 1,467
  • 3
  • 20
  • 37
  • If you do `grep PYTHON_CPPFLAGS /path/to/your/build/directory/gdb/config.log` (or `config.status`) , do the `-I` options refer to a directory that contains `Python.h` ? – Mark Plotnick Oct 27 '20 at 14:41
  • No, I can't find any PYTHON_CPPFLAGS at all, not in the makefile either. There are several places in both config.log and config.status where my "--with-python" string is recorded, but nowhere where it appears that any action has been taken in the light of it. – Eos Pengwern Oct 27 '20 at 15:15
  • OK, look in `config.log` in the `build/gdb` directory for lines starting with `checking whether to use python` and `checking compiler flags for python code` and see if the test programs succeeded. – Mark Plotnick Oct 27 '20 at 15:39
  • Hm.. Everything in the gdb/config.log file looks as I'd expect it to. The Python tests are run, they come back as "result: yes", and PYTHON_CPPFLAGS is defined correctly within the gdb/config.log file and the gdb/config.status file (in my previous reply I'd made the mistake of only looking in the main build directory, not in the gdb subdirectory). The correct path to Python.h is then included within the definition of INTERNAL_CPPFLAGS in gdb/Makefile. But the build still fails as originally described. – Eos Pengwern Oct 27 '20 at 23:22
  • I can also see that, within gdb/config.h, the macro WITH_PYTHON_LIBDIR is correctly set to the directory that contains my libpython2.7.so.1.0 file. – Eos Pengwern Oct 27 '20 at 23:25
  • The thing that's "custom" about my Python 2.7.18 build is that it was made using the -fno-semantic-interposition compiler switch and --default-symver linker switch. Might this have any effect? I can't tell whether the "undefined reference" error message refers to the compilation stage or the linker stage, though the fact that it's associated with a .h file makes the former more likely. – Eos Pengwern Oct 27 '20 at 23:29
  • See note below: "Finally, just for kicks, I did the same again, setting --with-python to the system Python installation in /usr/bin/python. That worked just fine! So clearly the problem is with my own Python build itself (though it works fine for everything else I've tried doing with it), or some very obscure aspect of the path to it." – Eos Pengwern Oct 27 '20 at 23:53
  • Can you give us the arguments you gave to `.../configure` for both gdb and python? – Mark Plotnick Oct 28 '20 at 17:10
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/223773/discussion-between-eos-pengwern-and-mark-plotnick). – Eos Pengwern Oct 28 '20 at 17:21

1 Answers1

0

I did something similar recently, and also struggled, although for different problems.

I suspect your build issue might be related to your use of LD_LIBRARY_PATH, or other things coming from your environment (PATH, CFLAGS, LDFLAGS etc). You shouldn't have to set these during the build.

Here's outline of what I did:

(1) For the build of gdb, I used approach like this:

export PATH=/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin
unset LD_LIBRARY_PATH 
../gdb-10.1/configure --prefix=/opt/gdb-10.1  --with-python=/opt/conda-py2.7.18 
make         &> make.log
make install &> make-install.log

The set of PATH and unset of LD_LIBRARY_PATH are intended to sanitise the environment. This ensures the build can only use --with-python for locating python (which itself is at bin/python, under the python prefix). (CFLAGS & LDFLAGS were also not set, nor any PYTHON variables.)

I kept the output of the make stage. If you look in there you should see the with-python option is picked up.

This all built fine.

(2) To invoke the debugger (and use my python under /opt), I needed an extra step: to set LD_LIBRARY_PATH so that my pythons libpython is used:

export LD_LIBRARY_PATH=/opt/conda-py2.7.18/lib
/opt/gdb-10.1/bin/gdb
(gdb) python import sys; print(sys.version)
2.7.18 | Anaconda, Inc.

It would be nice to find a way to avoid this need to set LD_LIBRARY_PATH; this would possibly require linking libpython statically, or introduction of some build flags, eg, to use rpath.

Darren Smith
  • 2,261
  • 16
  • 16
  • Let's have a go; this whole issue came to light when I set LD_LIBRARY_PATH, since before I did that my own application couldn't find ist necessary Python build. It was once I'd set it that I found my application sort-of worked but the debugger no longer did! – Eos Pengwern Oct 27 '20 at 15:16
  • OK, I tried building again with a minimal PATH, an empty LD_LIBRARY_PATH and making sure no PYTHON variables i.e. PYTHONPATH/PYTHONHOME) or FLAGS variables were set. I also tried it on a completely different machine, with the same Python build. Same result. Finally, just for kicks, I did the same again, setting --with-python to the system Python installation in /usr/bin/python. That worked just fine! So clearly the problem is with my own Python build itself (though it works fine for everything else I've tried doing with it), or some very obscure aspect of the path to it. – Eos Pengwern Oct 27 '20 at 23:52
  • When you built your custom python, did you add `--with-pydebug` to make a debug build? That can introduce extra debug symbols (such as _Py_RefTotal), so might be another cause. – Darren Smith Oct 28 '20 at 11:14
  • Interesting you should say that: everything reported above about my custom build concerned the version of it compiled with --with-pydebug. I have another build that was compiled without it, so I tried using this... and got some similar-but-different errors, this time concerning undefined references to PyUnicodeUCS2_Decode and other functions in that family. Now, I've also checked that my custom Python was compiled using UCS2 ("print sys.maxunicode" returns 65535), so I don't feel much the wiser. – Eos Pengwern Oct 28 '20 at 16:46
  • Well, the presence of those missing symbols like, `_Py_RefTotal`, is because you built python with `--with-pydebug`. I think you should try to make a simple & clean build of python, i.e., minimise number of flags, and see if that resolves things. Currently you have a few moving parts etc. – Darren Smith Oct 28 '20 at 17:24
  • For what it's worth, I've solved my underlying problem a different way. I've temporarily added the path to my custom Python build to the RPATH of my application (using CMake's BUILD_RPATH property) so that I can have my own application picking up the custom Python at the same time as gdb is using the standard Python. – Eos Pengwern Oct 28 '20 at 23:53