[Bug python/11051] Undefined Python linker messages

["zilla at kayari dot org" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From zilla at kayari dot org  2010-03-22 12:51 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11051

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.