glib installs a gdb helper file named "glib.py".
Then the "hook" file updates sys.path and does "import glib".

This will fail if glib has already been imported into gdb, say
using "from gi.repository import GLib".  This is due to a namespace clash.

One fix would be to rename the gdb helper files to not clash with
other Python modules.  This should be done for all such helper files.

This is not just theoretical; I have a gdb GUI written in Python
that runs inside gdb.  I encounter this bug whenever I try to debug
a glib-using program.  You can find my gui here:

https://github.com/tromey/gdb-gui


First, here is a demonstration of help helper working correctly:

pokyo. gdb -nx -quiet
(gdb) file /lib64/libglib-2.0.so.0.4600.2 
Reading symbols from /lib64/libglib-2.0.so.0.4600.2...Reading symbols from /lib64/libglib-2.0.so.0.4600.2...(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) info pretty-printer 
global pretty-printers:
  builtin
    mpx_bound128
  objfile /usr/lib64/libglib-2.0.so.0.4600.2 pretty-printers:
  pretty_printer_lookup
  objfile /usr/lib64/libglib-2.0.so.0.4600.2 pretty-printers:
  pretty_printer_lookup


Now here is how to reproduce the bug.  Note that I couldn't enter
the python stack trace here, as it caused problems for GNOME bugzilla.
I'll try to attach it separately.

pokyo. gdb -nx -quiet
(gdb) python from gi.repository import GLib
(gdb) file /lib64/libglib-2.0.so.0.4600.2 
Reading symbols from /lib64/libglib-2.0.so.0.4600.2...Reading symbols from /lib64/libglib-2.0.so.0.4600.2...(no debugging symbols found)...done.
Traceback (most recent call last):
[... error here ...]