Getting the GLib gdb macros with your own installed GLib

So there are these really cool debugging macros for GLib/GObject that do things like let you iterate GLists and pretty print GObjects and GHashTables and stuff that should nowadays be available in most distros.

Unfortunately when you build your own GLib to develop against, it all breaks.

It turns out, gdb locates when to load these things by looking in $prefix/share/gdb/auto-load/ and matching the sonames, so if you have libraries with a different soname (cause they’re new versions), or in a different prefix, it just doesn’t work.

Damien Lespiau has a workaround for this that adds a command to load them from a path you can control with sys.path; which works. I looked a little for a generic solution to feed the autoloader from my GLib build prefix, but I haven’t found one yet.

Having now looked at this. I’m also excited about possibilities for combining this with GObject-Introspection to potentially do some useful things. I don’t know what the caveats are here yet, what’s safe to call and what’s not.

Author: Danielle

Danielle is an Australian software engineer, computer scientist and feminist. She doesn't really work on GNOME any more (sadly). Opinions and writing are solely her own and so not represent her employer, the GNOME Foundation, or anyone else but herself.

3 thoughts on “Getting the GLib gdb macros with your own installed GLib”

  1. Ideally, gdb would go look for these python modules on $DIR/gdb/auto-load/ for each $DIR on $XDG_DATA_DIRS (and internally take care of PYTHONPATH through sys.path for example) and load the first libglib-2.0.whatever.py/libgobject-2.0.whatever.py it encounters. Build tools like jhbuild (and it’s shell command) already set $XDG_DATA_DIRS, so we’d get instant integration with those too…

    A differently named search path ($GDB_PYTHON or whatever) would work too off course, but we already have http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html, so little reason to reinvent the wheel I guess 😉

  2. @dieterv: I agree, I had a little bit of a poke around to see if there would be an obvious way to make the autoloader use XDG_DATA_DIRS, but nothing immediately came of it.

  3. File a gdb bug report with all the needed details. Maybe we can work something out.

    Also please file bug reports for any gdb features you need to be exposed to Python. We’ve mostly written the API by targeting specific user features, so there are holes where we haven’t had a need.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-ShareAlike 2.5 Australia
This work by Danielle Madeley is licensed under a Creative Commons Attribution-ShareAlike 2.5 Australia.