Thread: readline selection (was Re: [GENERAL] psql leaking? - SOLVED)

"Russ Brown" <postgres@dot4dot.plus.com> writes:
> It seems that the postgesql build process picked up and
> used libedit instead of readline: don't know if that's a core issue or a
> gentoo ebuild issue...

Hmm.  Our configure code is *supposed* to be biased to choose readline
over libedit, but I think maybe the code needs a little work.  It's
doing

for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
  for pgac_rllib in -lreadline -ledit ; do
    [ take the first working combination ]

ISTM it's possible for this to select libedit over readline when both
are available, if libedit chances to link with an earlier pgac_lib
alternative than readline does.

And that only affects the link choice.  The choice of headers is made
separately and would go for the readline headers if available, no matter
what had happened in the link choice.  It seems likely to me that your
failure has to do with compiling against readline headers and then
linking against libedit.  Saying that libedit "don't work" with psql
is too simplistic, because it *do* work, at least for some people.

ISTM that we ought to

(1) modify PGAC_CHECK_READLINE so that it really does prefer readline
over libedit consistently.  I think all this would take is switching
the loop order:

for pgac_rllib in -lreadline -ledit ; do
  for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do

but possibly I'm missing something.

(2) fix the readline header selection so that it will only take the
headers that correspond to the selected library.  These libraries are
more or less source-compatible but they do not have the same ABI, so
mix-and-match is not going to work.

Peter, any comments?  Do you have time to fix this?

            regards, tom lane

Tom Lane wrote:
> (1) modify PGAC_CHECK_READLINE so that it really does prefer readline
> over libedit consistently.  I think all this would take is switching
> the loop order:
>
> for pgac_rllib in -lreadline -ledit ; do
>   for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
>
> but possibly I'm missing something.

That seems reasonable.  I'm not really sure why the loops are nested the
other way.

> (2) fix the readline header selection so that it will only take the
> headers that correspond to the selected library.  These libraries are
> more or less source-compatible but they do not have the same ABI, so
> mix-and-match is not going to work.

That sounds like a pretty hard problem to solve.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> (2) fix the readline header selection so that it will only take the
>> headers that correspond to the selected library.

> That sounds like a pretty hard problem to solve.

It didn't seem that bad to me.  One problem is to not select, eg,
<readline/readline.h> in preference to <editline/readline.h> if we've
selected libedit for linking to.  (I think that is the behavior that
bit Russ.)  But that seems a small matter of paying attention to a flag
variable set by PGAC_CHECK_READLINE.  The other problem is that if we
select <readline.h> we can't really be sure it matches the selected
library.  I'm not sure that we *need* to solve that --- if you have
readline.so and not <readline/readline.h> then <readline.h> had better
be the right thing.  But I would think it could be done with some
appropriate AC_EGREP_HEADER check if you wanted to be paranoid.

            regards, tom lane