Re: Undefined symbol while executing Python

[Paul Koning <paul_koning at dell dot com>]

On Jul 1, 2011, at 10:08 PM, Joel Brobecker wrote:

>>> (gdb) python import itertools
>>> Traceback (most recent call last):
>>> File "<string>", line 1, in ?
>>> ImportError: /usr/lib/python2.4/lib-dynload/itertoolsmodule.so: undefined symbol: PyObject_SelfIter
>>> Error while executing Python code.
> [...]
>> More...  The symbol is defined in libpython2.4.so.  The native 7.0.1
>> gdb has that library in its required libraries list.  The cross 7.2
>> gdb I built does not.  That makes sense, it alllows that gdb to be
>> executed on another machine that might not have the same python
>> installed.  
> 
> Is GDB linked against the shared libpython? From what you are saying,
> it seems like it is.  But I know that there are problems when linking
> against the static version of libpython.  I have the following change
> in python-config.py to deal with the same sort of issue after I linked
> GDB with the static libpython.
> 
> +                if platform.system() == 'Linux':
> +                    # Make sure that the loader can resolve symbols from
> +                    # the libpython archive when loading modules implemented
> +                    # as DSOs (Eg: "import time").  This is to work around
> +                    # a side-effect of linking against the static version
> +                    # of libpython.
> +                    libs.insert(0, '-Xlinker -export-dynamic')

Thanks, that cured the problem (once I figured out where to insert it).  It turns out that, while there is a /usr/lib/libpython2.4, the gdb link is done against /usr/lib/python2.4/config/libpython2.4.a.  I'm not sure why.  It's probably actually a good thing because that binary is being built for a group of people, some of whom have a different version of python installed.

Anyway, it would be good if gdb built correctly (i.e., with that switch) out of the box rather than requiring manual non-obvious hacking.

	paul