Dynamic linker

bruce bushby bruce.bushby at gmail.com
Wed Mar 23 14:12:27 UTC 2011


Hi

I'm new to uclibc and buildroot so please forgive any stupid statements. I'm
stuck on a problem that I can't fix, as a last resort I'm wondering if it
could be (ld-uClibc.so.0)

Using buildroot, I am able to compile "ncurses" without any problems. I'm
also able to compile "readline" (which detects ncurses) and finally I'm able
to compile python-2.7.1 which detects "readline".

I boot the embedded OS and I can see all the relevant files:

[root at vx-200 ~]#
[root at vx-200 ~]# uname -a
Linux vx-200 2.6.38-rc5 #1 Wed Mar 23 12:10:46 GMT 2011 armv5tejl GNU/Linux
[root at vx-200 ~]#

[root at vx-200 ~]# find / -name "*readline*" | grep ython
/usr/lib/python2.7/lib-dynload/readline.so
[root at vx-200 ~]#

[root at vx-200 ~]# find / -name "*libreadline*"
/usr/lib/libreadline.so.6.1
/usr/lib/libreadline.so
/usr/lib/libreadline.a
/usr/lib/libreadline.so.6
[root at vx-200 ~]#

[root at vx-200 ~]# find / -name "*ncurses*"
/usr/lib/libncurses.so.5
/usr/lib/libncurses.so
/usr/lib/libncurses.a
/usr/lib/libncurses.so.5.7
/usr/bin/ncurses5-config
/usr/include/ncurses.h
/usr/include/ncurses_dll.h
[root at vx-200 ~]#
[

[root at vx-200 ~]# ldd /usr/lib/python2.7/lib-dynload/readline.so
checking sub-depends for '/usr/lib/libreadline.so.6'
checking sub-depends for '/usr/lib/libncurses.so.5'
checking sub-depends for '/lib/libc.so.0'
        ld-uClibc.so.0 => /lib//ld-uClibc.so.0 (0x40201000)
        libreadline.so.6 => /usr/lib/libreadline.so.6 (0x00000000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00000000)
        libc.so.0 => /lib/libc.so.0 (0x00000000)
        /lib//ld-uClibc.so.0 => /lib//ld-uClibc.so.0 (0x00000000)
[root at vx-200 ~]#


[root at vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetent
tgetent
[root at vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetnum
tgetnum
[root at vx-200 ~]#



So far everything looks perfect, Python's "lib-dynload/readline.so" is
linked against "libreadline"....and "libreadline" has the curses terminfo
symbols (tgetent, tgetflag, tgetnum, tgetstr, tgoto, tputs)

Next I try and run python, hoping for an interactive shell, the following
"strace -e trace=open python" command shows the relevant bits and the
resulting error:
[root at vx-200 ~]# strace -e trace=open python
........
open("/usr/lib/python2.7/lib-dynload/readline.so", O_RDONLY|O_LARGEFILE) = 3
open("/usr/lib/python2.7/lib-dynload/readline.so", O_RDONLY) = 4
open("/usr/lib/libreadline.so.6", O_RDONLY) = 4
open("/usr/lib/libncurses.so.5", O_RDONLY) = 4
open("/lib/libc.so.0", O_RDONLY)        = 4
open("/lib/libc.so.0", O_RDONLY)        = 4
open("/lib/libc.so.0", O_RDONLY)        = 4
open("/lib/ld-uClibc.so.0", O_RDONLY)   = 4

python: symbol 'BC': can't resolve symbol

python: symbol 'PC': can't resolve symbol

python: symbol 'UP': can't resolve symbol

python: symbol 'tgetnum': can't resolve symbol

python: symbol 'tgoto': can't resolve symbol

python: symbol 'tgetflag': can't resolve symbol

python: symbol 'tputs': can't resolve symbol

python: symbol 'tgetent': can't resolve symbol

python: symbol 'tgetstr': can't resolve symbol
>>>


So the Python binary opens "lib-dynload/readline.so" ...and the necessary
libreadline and libncurses ..... and lastly it opens "ld-uClibc" which, from
my limited understanding would link the addresses
of "readline" and "libncurses" (which I know contain the symbols) .....but
apparently they can't be resolved.

Could this be a dynamic linking problem?

Any help would be much appreciated!!

Thanks
Bruce


More information about the uClibc mailing list