[GRASS-dev] Configuring --with-readline doesn't use -lncurses or -ltermcap

[Glynn Clements]

Brad Douglas wrote:

> > How is it meant to know *which* library to use? Both provide the
> > necessary functions (as does -ltinfo if you have that library), but
> > they don't necessarily behave the same (particularly on platforms
> > other than Linux, where e.g. -ltermcap may actually use the termcap
> > database while -lncurses may use the terminfo database).
> > 
> > Ideal:
> > The OS vendor adds the correct library as a dependency of libreadline.
> > 
> > On my system (Gentoo):
> > 
> > $ ldd /lib/libreadline.so
> > 	linux-gate.so.1 =>  (0xffffe000)
> > 	libncurses.so.5 => /lib/libncurses.so.5 (0xb7f65000)
> > 	libc.so.6 => /lib/libc.so.6 (0xb7e4c000)
> > 	/lib/ld-linux.so.2 (0x80000000)
> > 
> > --with-readline works fine here.
> > 
> > I consider this a WONTFIX until someone comes up with a coherent
> > answer to the question of how to choose amongst multiple competing
> > "providers" of tgetent etc.
> 
> FYI, this is what RedHat has to say (from bug tracker):
> 
> "There are people who need to link against termcap, and people who need
> to link against ncurses.  The choice has to be made at compile time for
> *their* app, not readline."

Right.

One issue is that, if readline was linked against libtermcap (or if
configure added that library to $(READLINELIB)), and the application
needed both libreadline and libcurses, it would end up getting linked
against all three, with the result that libtermcap and libcurses would
clash over tgetent etc. And vice-versa.

On Linux, universally linking against libncurses is reasonably safe,
as that provides a strict superset of the functionality available
through libtermcap and libtinfo without adding any additional
dependencies. The GNU version of all of those libraries all use
terminfo by default with termcap as a fallback, so you get the same
behaviour from all of them.

AFAICT, the only real issue is namespace pollution, i.e. the
executable (or some other library) may export a symbol which clashes
with libcurses but not with libtermcap or libtinfo.

> > On a related note: how many people actually feed complex expressions
> > to r.mapcalc via stdin?
> 
> I have on rare occasion, but I certainly did not require readline to do
> so.  I don't think the prompt has any real significance anymore.  I find
> it more useful (and more to GRASS style) to use 'map=expression' and
> script it if I need repetition.

FWIW, my usual terminal is an XEmacs shell-mode buffer, so I don't
have any need for readline. I only use xterm for programs which insist
on using curses or ^H/^M tricks (G_percent() is *not* my friend).

> I vote to remove readline.

Leaving it in for the cases where it does work is only harmful insofar
as some people just *have* to have --with-everything. Removing it
wouldn't provide any real benefit (other than eliminating the feeling
that someone else is getting something which they aren't).

AFAICT, the only other practical option would be to add a (e.g.) 
--with-readline-aux-libs= option so that the user can provide any
additional switches (e.g. --with-readline-aux-libs=-ltermcap).

-- 
Glynn Clements <glynn at gclements.plus.com>