On Wed, Mar 23, 2011 at 10:12 AM, bruce bushby wrote: > 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)
what version of uClibc exactly are you using ? > [root@vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetent > tgetent > [root@vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetnum > tgetnum this is a terrible way of looking for symbols. what you're actually seeing is that readline *needs* those; it does not *provide* them. use `readelf -s` to actually see the difference. > 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) > > 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 no, readline does not provide any of these ... ncurses does. verify ncurses is correctly exporting these symbols with readelf. > 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 not quite. ld-uClibc in the output above is opened only because it was listed as DT_NEEDED. python, assuming it is a dynamic ELF, already had ld-uClibc loaded up and resolving symbols for you. -mike _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
