[oi-dev] 415 libreadline.so.5: symbol tgetent ... not found
Gordon Ross
gordon.w.ross at gmail.com
Thu Jun 30 05:32:23 UTC 2011
So the real issue here is a conflict between two goals:
1: libreadline should properly express its dependencies
(so we don't have to add bogus -lcurses to link lines)
2: libreadline should not force the selection of any particular
curses library.
The way libreadline used to link with libcurses did (1) but
failed at (2), essentially forcing use of libcurses even if
you were trying to use ncurses or xcurses. The current
libreadline satisfies (2) but fails at (1). sigh...
I looked into this a bit more, and there's a really nice
way to deal with this using a "filter" library. A new
filter library (libtermcap.so.1) exports the traditional
(BSD-style) termcap functions, but marks all those
exported symbols as NODIRECT. That way, the
consuming library or application can link with a
different curses implementation, and if it provides
those symbols, those will be used instead.
I tried this out and it works great! have a look:
http://www.yalms.org/cr/libtermcap/
If we build and install this libtermcap (filter) and then
rebuild libreadline to use it (with the fix I suggested
previously) it satisfies both goals (1) and (2).
I tested this with both an ncurses program and
one that does not link any curses (just readline)
and verified it calls the correct tgetent (ncurses
one when that's linked in, otherwise libcurses).
More information about the oi-dev
mailing list