"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
