Undefined symbol while executing Python

Undefined symbol while executing Python

[Paul Koning]

My Red Hat system has installed on it Pythong 2.4.3 and gdb 7.0.1.  Both of these process the Python command "import itertools" without complaint.

On that system I built gdb 7.2 (with some local mods, but not in the Python pieces).  That one blows up when I try that command:

GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=mips64el-pss-netbsdelf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(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.
(gdb) quit

Any ideas what's wrong or how to fix this?

	paul

Re: Undefined symbol while executing Python

[Paul Koning]

On Jul 1, 2011, at 3:37 PM, Paul Koning wrote:

> My Red Hat system has installed on it Pythong 2.4.3 and gdb 7.0.1.  Both of these process the Python command "import itertools" without complaint.
> 
> On that system I built gdb 7.2 (with some local mods, but not in the Python pieces).  That one blows up when I try that command:
> 
> GNU gdb (GDB) 7.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=mips64el-pss-netbsdelf".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> (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.
> (gdb) quit
> 
> Any ideas what's wrong or how to fix this?

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.  

So this suggests that libpython2.4 should have been loaded at this point and hasn't been, either that or the symbol name resolution isn't working right.

	paul

Re: Undefined symbol while executing Python

[Joel Brobecker]

> > (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')

-- 
Joel

Re: Undefined symbol while executing Python

[Paul Koning]

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

Re: Undefined symbol while executing Python

[Joel Brobecker]

> 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.

It's been a while since I looked at this, but I do remember that
the Python team has decided that the default way of doing things
is to create the static lib, and to link against the static lib.

Things get a little fuzzier for me on how the Python binaries
are built for the various distros, as they all build Python
with the shared version available.  ISTR that some systems
have a shared libpython on the one hand, and then a python install
that was build with static python. As a result, python-config.py
would still think that python was statically linked and would
think that there is no shared libpython.

Anyways, I'm just rambling, and could be completely off the mark.

> 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.

I can't remember why I never submitted this patch. But I remember
that some of the changes we made in-house at AdaCore were not
suitable for everyone, and thus were withdrawn.

I can look again at submitting this bit, if I can convince myself
(and others) that it doesn't have a potential negative impact, but
right now is not the best time for me :-(.

-- 
Joel