I get a number of linker messages along the line of "undefined reference to `PyUnicodeUCS2_Decode'" I saw someone had a similar issue for Samba (http://lists.samba.org/archive/samba/2008-June/141536.html) indicating this may be due to a bad Python install, but it got no replies. I'm not that familar with Python, but I noticed that while in /usr/lib/libpython2.4.so there is no PyUnicodeUCS2_Decode, there is a PyUnicodeUCS4_Decode. Please let me know what other info you need. GDB: 7.0 GCC: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46) OS: CentOS 5.3 Python: Python 2.4.6 Relevant output: [mcmaster@gespenst gdb-7.0]$ make ... gcc -g -O2 \ -o gdb gdb.o libgdb.a \ ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lncurses -lz -lm -lpython2.4 -lexpat ../libiberty/libiberty.a gnulib/libgnu.a -ldl -rdynamic libgdb.a(py-cmd.o): In function `cmdpy_completer': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-cmd.c:197: undefined reference to `PyUnicodeUCS2_Decode' /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-cmd.c:200: undefined reference to `PyUnicodeUCS2_Decode' libgdb.a(py-cmd.o): In function `cmdpy_function': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-cmd.c:138: undefined reference to `PyUnicodeUCS2_Decode' libgdb.a(py-frame.o): In function `frapy_name': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-frame.c:132: undefined reference to `PyUnicodeUCS2_Decode' libgdb.a(py-frame.o): In function `gdbpy_frame_stop_reason_string': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-frame.c:407: undefined reference to `PyUnicodeUCS2_Decode' libgdb.a(py-type.o):/home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-type.c:519: more undefined references to `PyUnicodeUCS2_Decode' follow libgdb.a(py-utils.o): In function `unicode_to_encoded_python_string': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-utils.c:117: undefined reference to `PyUnicodeUCS2_AsEncodedString' libgdb.a(py-utils.o): In function `unicode_to_encoded_string': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-utils.c:96: undefined reference to `PyUnicodeUCS2_AsEncodedString' libgdb.a(py-utils.o): In function `python_string_to_unicode': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-utils.c:73: undefined reference to `PyUnicodeUCS2_FromEncodedObject' libgdb.a(py-value.o): In function `valpy_string': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-value.c:254: undefined reference to `PyUnicodeUCS2_Decode' libgdb.a(py-value.o): In function `valpy_str': /home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb/./python/py-value.c:384: undefined reference to `PyUnicodeUCS2_Decode' collect2: ld returned 1 exit status make[2]: *** [gdb] Error 1 make[2]: Leaving directory `/home/mcmaster/document/software/GNU/GDB/gdb-7.0/gdb' make[1]: *** [all-gdb] Error 2 make[1]: Leaving directory `/home/mcmaster/document/software/GNU/GDB/gdb-7.0' make: *** [all] Error 2
On first blush this look like the cause reported in the FAQ (which deals with how Python is built for different environments): http://www.python.org/doc/faq/extending/#when-importing-module-x-why-do-i-get-undefined-symbol-pyunicodeucs2 Can you run the testcase for determining the issue at the end of that article and let us know? Thanks
I'm getting the same error building GDB 7.1 on CentOS 5.3, with python 2.4 installed in /usr from rpm, and Python 2.6 in /usr/local Python 2.6 comes first in my path so I expect that to be found by configure: $ which python /usr/local/bin/python When I configure with --with-python=/usr/local or with no --with-python the linker commands include -lpython2.6 (as expected) but I get undefined references to the UCS2 symbols, and indeed the /usr/local/lib/libpython2.6.so library doesn't have those symbols: $ nm /usr/local/lib/libpython2.6.so | fgrep UnicodeUCS2 | wc -l 0 $ nm /usr/local/lib/libpython2.6.so | fgrep UnicodeUCS4 | wc -l 84 The sys.maxunicode test gives $ /usr/local/bin/python Python 2.6.2 (r262:71600, Aug 18 2009, 15:29:02) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> if sys.maxunicode > 65535: ... print 'UCS4 build' ... else: ... print 'UCS2 build' ... UCS2 build >>> $ $ /usr/bin/python Python 2.4.3 (#1, Jul 27 2009, 17:56:30) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> if sys.maxunicode > 65535: ... print 'UCS4 build' ... else: ... print 'UCS2 build' ... UCS4 build >>> I thought I would try to solve the problem by telling configure to use the UCS4 build of python2.4 in /usr, but when I configure with --with-python=/usr the gdb-7.1/gdb/configure script still finds python2.6 configure:9442: checking whether to use python configure:9444: result: /usr/ configure:9478: checking for python2.6 configure:9493: gcc -o conftest -g -O2 -I/usr//include conftest.c -lncurses -lz -lm -L/usr//lib -lpython2.6 >&5 /usr/bin/ld: skipping incompatible /usr//lib/libncurses.so when searching for -lncurses /usr/bin/ld: skipping incompatible /usr//lib/libncurses.a when searching for -lncurses /usr/bin/ld: skipping incompatible /usr//lib/libz.so when searching for -lz /usr/bin/ld: skipping incompatible /usr//lib/libz.a when searching for -lz /usr/bin/ld: skipping incompatible /usr//lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr//lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr//lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr//lib/libc.a when searching for -lc configure:9493: $? = 0 configure:9501: result: yes There are a couple of problems here. For a 64-bit OS LDFLAGS should use -L/usr/lib64 not -L/usr/lib, secondly if libpython2.6 is found then it will be used, even if it's not the one requested via --with-python (this might be unavoidable in a case like mine where python2.6 has been installed in /usr/local, because GCC looks in /usr/local/lib for libraries.) I can't change where python2.6 is installed, but I'd like to be able to use it, which means I need to know why python2.6 reports a UCS2 build, but the library only contains UCS4 symbols. Presumably that is why gdb/python/py-cmd.c tries to link to the UCS2 symbols and then fails to find them.
Hmm, curiously /usr/local/bin/python doesn't depend on libpython2.6.so which might explain how it can report a UCS2 build when the lib only contains UCS4 symbols $ ldd /usr/local/bin/python libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003848e00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003848a00000) libutil.so.1 => /lib64/libutil.so.1 (0x000000384e200000) libm.so.6 => /lib64/libm.so.6 (0x000000384b200000) libc.so.6 => /lib64/libc.so.6 (0x0000003848200000) /lib64/ld-linux-x86-64.so.2 (0x0000003847a00000)
Looks like my headers don't match my .so: $ fgrep Py_UNICODE_SIZE /usr/local/include/python2.6/pyconfig.h #define Py_UNICODE_SIZE 2 So that explains why GDB tries to link to the UCS2 symbols.
Yes, we have a borked python2.6 installation. To the OP: check which pyconfig.h GDB is including and see what it sets Py_UNICODE_SIZE to. That needs to match what was used to build libpython2.4.so To the GDB maintainers: I think the configure checks for python could be improved, but at least in my case this bug seems to be caused by user error.
Yes, that's the idea I was trying to get across when I posted this: if this is a user error, is it possible for configure to notify us rather than during build? And now from the FAQ entry that was pointed to, it seems that this is a pretty common issue and would be worth checking for if relatively easy to check for. I did verify that there was a mismatch in python files and was able to eliminate the second Python installation which seems to have fixed the problem. However, part of the the idea of configure is to make sure the build environment is sane, and this seemed big enough that would be worthwhile to be checked in configure.
"To the OP: check which pyconfig.h GDB is including and see what it sets Py_UNICODE_SIZE to. That needs to match what was used to build libpython2.4.so To the GDB maintainers: I think the configure checks for python could be improved, but at least in my case this bug seems to be caused by user error." I'm not sure how we have GDB's configure check the PU_UNICODE_SIZE against what was used to build libpython2.so. I'm not expert here, by far.
(In reply to comment #7) > I'm not sure how we have GDB's configure check the PU_UNICODE_SIZE against what > was used to build libpython2.so. I'm not expert here, by far. We probably don't want to do that. It seems reasonable to me to assume that Python is installed correctly. The configury here has all been redone in CVS. I think it is somewhat more robust. So, I'm closing this; if you think that this is in error, please reopen.