Hi I'm hoping the list could give me some insight into how python behaves when it has been compiled with "readline".
I sent the following email to the uClibc list which describes my problem, any tips or pointers would be much appreciated! Thanks Bruce .... 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@vx-200 ~]# [root@vx-200 ~]# uname -a Linux vx-200 2.6.38-rc5 #1 Wed Mar 23 12:10:46 GMT 2011 armv5tejl GNU/Linux [root@vx-200 ~]# [root@vx-200 ~]# find / -name "*readline*" | grep ython /usr/lib/python2.7/lib-dynload/readline.so [root@vx-200 ~]# [root@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@vx-200 ~]# [root@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@vx-200 ~]# [ [root@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@vx-200 ~]# [root@vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetent tgetent [root@vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetnum tgetnum [root@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@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
-- http://mail.python.org/mailman/listinfo/python-list