Should libedit be preferred to libreadline?

Nice analysis, but we can't hack configure like that. It has to be able
to be fully generated from its sources. I think the other source file
you would need to look at is config/programs.m4. (Not sure about quoting
$ac_popdir - why only that one?)

Also, I suspect we'd want to enable the libedit preference with a switch
rather than just force it, if we want to go this way.

cheers

andrew

Seneca Cunningham wrote:

It would certainly seem so on AIX.

In tracking down why postgres 8.x would segfault on AIX 5.3, it became
apparent to me that libreadline.a is a problematic library to link
against and that libedit.a is preferable (and for reasons other than
that readline is GPL while postgres is BSD-licensed).

With AIX 5, the easiest way to get a shared object is to pass "-bexpall"
to the linker. This results in all symbols being exported. The problem
with this is that the linker will export all of libreadline's and
libhistory's symbols. In the case of libreadline.so.4 (and .5) on AIX 5
this includes symbols like strncpy and memmove, but on .4, not memcpy.
This is likely because libc.a does not export them.

What results from this is that when postgres is linked against readline
on AIX, it gets these memory functions through readline instead of its
own code. When readline 4.3 is used (what IBM provides in their "AIX
Toolbox for Linux"), postgres is known to crash. These segfaults (if
postgres was compiled with gcc) have occurred on AIX 5.3ML3, AIX 5.3ML1,
and AIX 5.2ML7. With readline 5.0, postgres merely gets these functions
through the shared library memory segments instead of the user memory
segments[6].

While it is possible to build libreadline in a manner that doesn't
export strncpy, neither of the prebuilt readlines for AIX 5 that I
checked were both shared and did not export strncpy. IBM's readline[5]
exports strncpy, UCLA's readline[4] is static. Building a shared
readline that doesn't export strncpy requires creating export files for
libreadline and libhistory that only list the symbols that they are
supposed to export and editing the shared library Makefile to add the
exports flags to the appropriate linker calls.

Whatever strategy we might take, using readline on AIX requires
considerable trickery and hacking around with the build environments.
Simply put, it's ghastly.

On the other hand, the port of NetBSD's editline that I tried[1] works
without build-hackery to the library and has reasonable exports. The
only changes to postgres that I needed to make were confined to telling
the configure script to check for libedit before libreadline and adding
a test for histedit.h. The attached patch contains my modifications.

It is also possible to use a wrapper like rlwrap[2] instead of linking
postgres against libreadline or libedit.

[1] port of NetBSD's editline
http://www.thrysoee.dk/editline/
[2] rlwrap
http://utopia.knoware.nl/~hlub/uck/software/
[3] IBM Redbook "AIX 5L Porting Guide", section 9.2
http://www.redbooks.ibm.com/abstracts/sg246034.html?Open
http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf
[4] UCLA's readline package
http://aixpdslib.seas.ucla.edu/packages/readline.html
[5] IBM's readline package
http://www-03.ibm.com/servers/aix/products/aixos/linux/download.html
[6] IBM Redbook "Developing and Porting C and C++ Applications on AIX",
page 110
http://www.redbooks.ibm.com/abstracts/sg245674.html?Open
http://www.redbooks.ibm.com/redbooks/pdfs/sg245674.pdf

[patch snipped]

Andrew Dunstan <andrew@dunslane.net> writes:

Also, I suspect we'd want to enable the libedit preference with a switch
rather than just force it, if we want to go this way.

Quite. My recollection is that there are other platforms on which
readline works and libedit is broken. (Readline used to work just
fine even on AIX ;-))

regards, tom lane

With AIX 5, the easiest way to get a shared object is to pass

"-bexpall"

to the linker. This results in all symbols being exported.

Yes, that is another reason not to use this broken switch.
And last time I checked (AIX 4.3.3), -bexpall did not export all needed
symbols
(e.g. globals) from the backend eighter. And the counterpart -bimpall
did also not work.
Dynamic loading did not work without the .imp and .exp files :-(

Andreas

PS: I'd prefer if readline was only linked where it is needed, namely in
psql.

On Tue, Nov 22, 2005 at 10:07:15AM +0100, Zeugswetter Andreas DCP SD wrote:

PS: I'd prefer if readline was only linked where it is needed, namely in
psql.

The problem as stated is that people don't want to maintain lists of
libraries as needed by each program, so we link all of them.

Since it seems to always be the same few libraries that cause us
problems, maybe a simpler approach would be to, in the Makefile, use
filter-out to exclude libraries you *know* aren't needed. Like in the
Makefile we put:

postgres: $(OBJS)
$(CC) $(CFLAGS) $(LDFLAGS) $(export_dynamic) $^ $(filter-out -lreadline -ledit, $(LIBS)) -o $@

So instead of maintaining lists of what each binary needs, we can
maintain a few lists of what certain binaries *don't* need. Actually, I
think the backend is the only thing important enough to worry about
this, although if readline is exporting memcpy that it's quite possible
other binaries might be affected. Maybe create a BACKEND_LIBS which
contains a shorter list.

Even the GCC --as-needed flag can't save you from libs exporting
functions they shouldn't...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

On Mon, Nov 21, 2005 at 07:50:48PM -0500, Andrew Dunstan wrote:

Nice analysis, but we can't hack configure like that. It has to be able
to be fully generated from its sources. I think the other source file
you would need to look at is config/programs.m4. (Not sure about quoting
$ac_popdir - why only that one?)

Also, I suspect we'd want to enable the libedit preference with a switch
rather than just force it, if we want to go this way.

BTW, we've run into issues with readline from a licensing standpoint. It
would be really nice if libedit was supported where practical (I suspect
most mainstream OSes support libedit) since it's BSD licensed.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Martijn van Oosterhout wrote:
-- Start of PGP signed section.

On Tue, Nov 22, 2005 at 10:07:15AM +0100, Zeugswetter Andreas DCP SD wrote:

PS: I'd prefer if readline was only linked where it is needed, namely in
psql.

The problem as stated is that people don't want to maintain lists of
libraries as needed by each program, so we link all of them.

Since it seems to always be the same few libraries that cause us
problems, maybe a simpler approach would be to, in the Makefile, use
filter-out to exclude libraries you *know* aren't needed. Like in the
Makefile we put:

postgres: $(OBJS)
$(CC) $(CFLAGS) $(LDFLAGS) $(export_dynamic) $^ $(filter-out -lreadline -ledit, $(LIBS)) -o $@

Agreed. I have no idea why this has not been done already.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Jim C. Nasby wrote:

On Mon, Nov 21, 2005 at 07:50:48PM -0500, Andrew Dunstan wrote:

Nice analysis, but we can't hack configure like that. It has to be able
to be fully generated from its sources. I think the other source file
you would need to look at is config/programs.m4. (Not sure about quoting
$ac_popdir - why only that one?)

Also, I suspect we'd want to enable the libedit preference with a switch
rather than just force it, if we want to go this way.

BTW, we've run into issues with readline from a licensing standpoint. It
would be really nice if libedit was supported where practical (I suspect
most mainstream OSes support libedit) since it's BSD licensed.

Why don't we have a libedit configure flag?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Why don't we have a libedit configure flag?

Well, I can code up a configure flag, but that doesn't mean that the
thing will compile at the end. :)

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

Peter Eisentraut wrote:

Bruce Momjian wrote:

Why don't we have a libedit configure flag?

Well, I can code up a configure flag, but that doesn't mean that the
thing will compile at the end. :)

Attached is a patch which adds a flag to configure to prefer
BSD-licensed libedit:

--with-preference-bsd-libedit prefer libedit over readline

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

--with-preference-bsd-libedit prefer libedit over readline

Can't it just be --with-libedit? That seems awfully verbose,
particularly seeing that configure doesn't handle switch abbreviation.

The patch looks OK offhand, though I didn't try to test it.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

--with-preference-bsd-libedit prefer libedit over readline

Can't it just be --with-libedit? That seems awfully verbose,
particularly seeing that configure doesn't handle switch abbreviation.

The problem is that we need a clear way to say we don't want any line
editing. Right now we do it with --without-readline. Also, we already
test for libedit if we don't find readline. Would we stop doing that?
And if we do that, do we tell them they have to say --without-readline
too? And if we don't, how do we handle it? I am just confused how to
clean this up without making thing worse. I am looking for ideas.

I guess my point is do we enable looking for readline and libedit by
default, and if we do how do we specify with to test for first, and how
do we specify we want no line editing functionaliy?

The patch looks OK offhand, though I didn't try to test it.

I tested it and it does look for libedit first when defined, and matches
the patch posted by the AIX user, except it is a configure option.

Oh, one good thing is that the new configure 2.59 we are using throws an
error now for invalid user-supplied configure options, rather than
silently ignoring it like it used to.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Can't it just be --with-libedit? That seems awfully verbose,
particularly seeing that configure doesn't handle switch abbreviation.

The problem is that we need a clear way to say we don't want any line
editing. Right now we do it with --without-readline. Also, we already
test for libedit if we don't find readline. Would we stop doing that?

Well, we could rename --without-readline to --without-editing, but
I think this would just break people's existing expectations without
adding much. I don't see a problem with documenting

--with-libedit prefer libedit over libreadline

and leaving the rest alone.

Oh, one good thing is that the new configure 2.59 we are using throws an
error now for invalid user-supplied configure options, rather than
silently ignoring it like it used to.

Really? I did "configure --with-bozo" and it didn't complain. It
does barf on "--bozo", but the autoconf boys have been insistent for
more than a decade that accepting --with-anything is a feature not
a bug. So I think --with-some-long-name is more user-unfriendly than
user-friendly.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Can't it just be --with-libedit? That seems awfully verbose,
particularly seeing that configure doesn't handle switch abbreviation.

The problem is that we need a clear way to say we don't want any line
editing. Right now we do it with --without-readline. Also, we already
test for libedit if we don't find readline. Would we stop doing that?

Well, we could rename --without-readline to --without-editing, but
I think this would just break people's existing expectations without
adding much. I don't see a problem with documenting

--with-libedit prefer libedit over libreadline

and leaving the rest alone.

That seems confusing because you would assume the default,
--without-libedit, would not use libedit, but it does.

I trimmed it down to:

--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-prefer-libedit prefer libedit over readline
--without-readline do not use Readline
--without-zlib do not use Zlib

I did preference -> prefer and removed 'bsd'. I could name it
--with-libedit-first. Is that better?

Oh, one good thing is that the new configure 2.59 we are using throws an
error now for invalid user-supplied configure options, rather than
silently ignoring it like it used to.

Really? I did "configure --with-bozo" and it didn't complain. It
does barf on "--bozo", but the autoconf boys have been insistent for
more than a decade that accepting --with-anything is a feature not
a bug. So I think --with-some-long-name is more user-unfriendly than
user-friendly.

Oh, I see, if you do --blah, it complains, but you are right,
--with-blah doesn't complain. Boohoo.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I trimmed it down to:
--with-prefer-libedit prefer libedit over readline

OK, I can live with that.

regards, tom lane

Bruce Momjian wrote:

I trimmed it down to:

--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-prefer-libedit prefer libedit over readline
--without-readline do not use Readline
--without-zlib do not use Zlib

I'm concerned that this still gives nondeterministic behavior. There's
no way to say, "I want readline, period" or "I want libedit, period".
I'd prefer simple --with-readline and --with-libedit, giving one turns
off the other, giving both is an error.

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

Peter Eisentraut <peter_e@gmx.net> writes:

I'm concerned that this still gives nondeterministic behavior. There's
no way to say, "I want readline, period" or "I want libedit, period".
I'd prefer simple --with-readline and --with-libedit, giving one turns
off the other, giving both is an error.

OTOH that doesn't provide a way to express "I'll take either". Given
that I'll-take-either has so far satisfied 99.44% of users, getting rid
of it doesn't seem like the best plan.

It might be possible to set things up so that you can specify "I'll take
either" by writing both switches, and further that the order in which
you write the switches determines the preference --- though I'm not
entirely sure how to do the latter within the autoconf framework.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I trimmed it down to:
--with-prefer-libedit prefer libedit over readline

OK, I can live with that.

I think it's ugly. Can't we just say --prefer-libedit ?

If must be a --with-foo flag, maybe --with-libedit-preferred or
--with-libedit-first would be better.

cheers

andrew

tgl@sss.pgh.pa.us (Tom Lane) writes:

Peter Eisentraut <peter_e@gmx.net> writes:

I'm concerned that this still gives nondeterministic behavior.
There's no way to say, "I want readline, period" or "I want
libedit, period". I'd prefer simple --with-readline and
--with-libedit, giving one turns off the other, giving both is an
error.

OTOH that doesn't provide a way to express "I'll take either".
Given that I'll-take-either has so far satisfied 99.44% of users,
getting rid of it doesn't seem like the best plan.

I'll bet that for well over 80% of those 99.44% (was this, by any
chance, part of the 80% in the infamous quote "80% of all statistics
quoted to prove a point are made up on the spot"??? :-)), that what
happens is that the satisfied users have taken a prepackaged copy of
PostgreSQL.

On my home installations, for instance, I'm satisfied with whatever
configuration Martin Pitt did when he built Debian packages for
PostgreSQL, and there are doubtless a lot of others being satisfied
identically.

Those that use .rpms that you manage for Red Hat, or that other
packagers manage for Mandriva, SuSE, FreeBSD Ports, and such, fall
into much the same category of "satisfaction" where a lot of the
99.44% are being satisfied by the choices of a set of on the order of
a dozen individuals that do packaging.

Those of us using packages, who are probably quite common, are a big
step indirected from this. We don't have a reason to prefer
determinism or nondeterminism in this matter; we'll get exactly one
choice, namely the choice that one or another of those ~ dozen people
make.

It might be possible to set things up so that you can specify "I'll take
either" by writing both switches, and further that the order in which
you write the switches determines the preference --- though I'm not
entirely sure how to do the latter within the autoconf framework.

I'll change hats; in my "overseeing binaries used at Afilias hat," my
vote would be with Peter, for determinism. I'm not particularly
interested in seeing psql "magically" configure itself to slightly
prefer one editing library over another; I'd be entirely happy with:

--with-readline
implying that GNU readline shall be used, and libedit shall not
--with-editline
implying that libedit shall be used, and GNU readline shall not

Supposing we were to change to this "deterministic semantic" for 8.2,
I don't see a grand problem, here. It seems likely to me that it
might confuse someone for all of 5 seconds when ./configure reports
back "Sorry, you don't have readline installed, so --with-readline
won't work!"

In contrast, the nondeterministic approach requires having extra knobs
to fiddle in order to prefer one thing to another. I'm not sure but
that "configure hints" are as unattractive as "optimizer hints" :-).

To my mind, giving BIG weight to the opinions of the relatively small
set of individuals that manage PostgreSQL packages for the popular
distributions of Linux and *BSD seems fairly appropriate.
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/advocacy.html
Rules of the Evil Overlord #25. "No matter how well it would perform,
I will never construct any sort of machinery which is completely
indestructible except for one small and virtually inaccessible
vulnerable spot." <http://www.eviloverlord.com/&gt;

Chris Browne <cbbrowne@acm.org> writes:

To my mind, giving BIG weight to the opinions of the relatively small
set of individuals that manage PostgreSQL packages for the popular
distributions of Linux and *BSD seems fairly appropriate.

The packagers are bright enough to adapt to whatever we do --- it's
the people who build their own from source that I'm worried about.
--with-readline has worked fine for libedit users for a long time,
and suddenly changing its semantics strikes me as a bad idea.

The other problem with the "let's be deterministic" argument is that
it rests on a fallacy, which is that configure can reliably tell the
difference between libreadline and libedit. Darwin, for example, goes
to some lengths to confuse matters.

(I think I'd actually be for the determinism point of view if it could
provide an #ifdef flag saying which library is in use --- then we could
fix the write_history return value problem we're seeing on Darwin ---
but I don't think we can do it short of a behavioral probe during
configure.)

regards, tom lane

Tom Lane wrote:

Chris Browne <cbbrowne@acm.org> writes:

To my mind, giving BIG weight to the opinions of the relatively small
set of individuals that manage PostgreSQL packages for the popular
distributions of Linux and *BSD seems fairly appropriate.

The packagers are bright enough to adapt to whatever we do --- it's
the people who build their own from source that I'm worried about.
--with-readline has worked fine for libedit users for a long time,
and suddenly changing its semantics strikes me as a bad idea.

The other problem with the "let's be deterministic" argument is that
it rests on a fallacy, which is that configure can reliably tell the
difference between libreadline and libedit. Darwin, for example, goes
to some lengths to confuse matters.

(I think I'd actually be for the determinism point of view if it could
provide an #ifdef flag saying which library is in use --- then we could
fix the write_history return value problem we're seeing on Darwin ---
but I don't think we can do it short of a behavioral probe during
configure.)

Let me add one more thing into the mix. Right now, you have to say
--without-readline if you don't want any command-line editing.
(Remember, configure will currently fail if it doesn't find readline or
libedit.) How will we do that if we have separate flags for readline
and libedit?

Right now, --with-readline is on by default, and fails if readline or
libedit can not be found. If we change to two flags, then we will have
to say --without-readline --with-libedit to get libedit to work, and
--without-readline and --without-libedit to configure for no line
editing capability. Does anyone want to try to explain that in an email
over and over again for 8.2? :-)

The basic problem is that with two deterministic flags the default
values for those flags are unclear. We really want to default to
looking for either of them, but want to the ability to give preference
to one over the other. Deterministic is great, but how do we do that
with reasonable defaults?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The basic problem is that with two deterministic flags the default
values for those flags are unclear.

That's a really good point ... the only explainable default would be
that both are --without, which is a crummy default.

I think the way that Bruce's patch works is fine, only the name of the
switch needs tweaking ;-)

regards, tom lane

Andrew Dunstan wrote:

I trimmed it down to:
--with-prefer-libedit prefer libedit over readline

I think it's ugly. Can't we just say --prefer-libedit ?

If must be a --with-foo flag, maybe --with-libedit-preferred or
--with-libedit-first would be better.

OK, changed:

--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer libedit over readline
--without-readline do not use Readline

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The basic problem is that with two deterministic flags the default
values for those flags are unclear.

That's a really good point ... the only explainable default would be
that both are --without, which is a crummy default.

I think the way that Bruce's patch works is fine, only the name of the
switch needs tweaking ;-)

Already renamed and patch posted:

--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer libedit over readline
--without-readline do not use Readline

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

--with-libedit-preferred prefer libedit over readline
--without-readline do not use Readline

Possibly
--without-readline do not use readline or libedit

In any case please be consistent about the capitalization ...

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

--with-libedit-preferred prefer libedit over readline
--without-readline do not use Readline

Possibly
--without-readline do not use readline or libedit

In any case please be consistent about the capitalization ...

OK, updated text:

--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

OK, updated text:

--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib

This all seems kind of extra... Why not just:

--with-libedit Use libedit instead of readline
--with-readline Use readline instead of libedit (default)
--without-readline Use when readline is not available

Joshua D. Drake

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl, ODBCng - http://www.commandprompt.com/

Joshua D. Drake wrote:

OK, updated text:

--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib

This all seems kind of extra... Why not just:

--with-libedit Use libedit instead of readline
--with-readline Use readline instead of libedit (default)
--without-readline Use when readline is not available

Did you read my later posting? There is no reasonable default for
those unless we want to disable libedit detection by default, and as Tom
mentioned, for OSX it isn't even clear which one you have found.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Fri, 2005-12-02 at 15:12 -0500, Bruce Momjian wrote:

Joshua D. Drake wrote:

OK, updated text:

--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib

This all seems kind of extra... Why not just:

--with-libedit Use libedit instead of readline
--with-readline Use readline instead of libedit (default)
--without-readline Use when readline is not available

Did you read my later posting? There is no reasonable default for
those unless we want to disable libedit detection by default,

Well that is why I said that --with-readline is the default ;)

and as Tom
mentioned, for OSX it isn't even clear which one you have found.

Hmmm... Can we change the config options based on FreeBSD/OSX? Where
if it is that platform libedit is the default?

Of course is OSX can't determine which one it is giving to the user that
seems like a PITA.

Joshua D. Drake

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl, ODBCng - http://www.commandprompt.com/

Bruce Momjian wrote:

In any case please be consistent about the capitalization ...

OK, updated text:

--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib

They are called "Readline" and "Libedit".

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

Peter Eisentraut wrote:

Bruce Momjian wrote:

In any case please be consistent about the capitalization ...

OK, updated text:

--with-openssl build with OpenSSL support
--with-libedit-preferred prefer Libedit over Libreadline
--without-readline do not use Libreadline/Libedit line editing
--without-zlib do not use Zlib

They are called "Readline" and "Libedit".

I wanted to distinguish libreadline from readline-functionality. Why is
it Readline?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

They are called "Readline" and "Libedit".

I wanted to distinguish libreadline from readline-functionality.

The functionality may be called "command-line editing" but I don't see
how that relates to what actually appears in the patch.

Why is it Readline?

PostgreSQL was already used.

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

Peter Eisentraut wrote:

Bruce Momjian wrote:

They are called "Readline" and "Libedit".

I wanted to distinguish libreadline from readline-functionality.

The functionality may be called "command-line editing" but I don't see
how that relates to what actually appears in the patch.

When you use --without-readline, it really means without libreadline and
libedit. One solution would be to rename that --without-lineediting,
but that might confuse people.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

I wanted to distinguish libreadline from readline-functionality. Why is
it Readline?

"The GNU Readline Library" is usually referred to as "Readline", not
"libreadline". The offical name for "libedit" is really "Libedit".

See e.g.:
http://sourceforge.net/projects/libedit/
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html

IMHO libreadline does not sound good.

Best Regards,
Michael Paesold

Michael Paesold wrote:

Bruce Momjian wrote:

I wanted to distinguish libreadline from readline-functionality. Why is
it Readline?

"The GNU Readline Library" is usually referred to as "Readline", not
"libreadline". The offical name for "libedit" is really "Libedit".

See e.g.:
http://sourceforge.net/projects/libedit/
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html

IMHO libreadline does not sound good.

OK, I call it GNU Readline now:

--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer BSD Libedit over GNU Readline
--without-readline do not use GNU Readline / BSD Libedit line editing
--without-zlib do not use Zlib

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Patch applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:

Michael Paesold wrote:

Bruce Momjian wrote:

I wanted to distinguish libreadline from readline-functionality. Why is
it Readline?

"The GNU Readline Library" is usually referred to as "Readline", not
"libreadline". The offical name for "libedit" is really "Libedit".

See e.g.:
http://sourceforge.net/projects/libedit/
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html

IMHO libreadline does not sound good.

OK, I call it GNU Readline now:

--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer BSD Libedit over GNU Readline
--without-readline do not use GNU Readline / BSD Libedit line editing
--without-zlib do not use Zlib

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure
===================================================================
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.462
diff -c -c -r1.462 configure
*** configure	5 Nov 2005 16:42:00 -0000	1.462
--- configure	3 Dec 2005 15:25:44 -0000
***************
*** 890,896 ****
--with-pam              build with PAM support
--with-bonjour          build with Bonjour support
--with-openssl          build with OpenSSL support
!   --without-readline      do not use Readline
--without-zlib          do not use Zlib
--with-gnu-ld           assume the C compiler uses GNU ld [default=no]

--- 890,897 ----
--with-pam              build with PAM support
--with-bonjour          build with Bonjour support
--with-openssl          build with OpenSSL support
!   --with-libedit-preferred  prefer BSD Libedit over GNU Readline
!   --without-readline      do not use GNU Readline / BSD Libedit line editing
--without-zlib          do not use Zlib
--with-gnu-ld           assume the C compiler uses GNU ld [default=no]

***************
*** 3772,3777 ****
--- 3773,3809 ----

#
+ # Prefer libedit
+ #
+ 
+ 
+ 
+ # Check whether --with-libedit-preferred or --without-libedit-preferred was given.
+ if test "${with_libedit_preferred+set}" = set; then
+   withval="$with_libedit_preferred"
+ 
+   case $withval in
+     yes)
+       :
+       ;;
+     no)
+       :
+       ;;
+     *)
+       { { echo "$as_me:$LINENO: error: no argument expected for --with-libedit-preferred option" >&5
+ echo "$as_me: error: no argument expected for --with-libedit-preferred option" >&2;}
+    { (exit 1); exit 1; }; }
+       ;;
+   esac
+ 
+ else
+   with_libedit_preferred=no
+ 
+ fi;
+ 
+ 
+ 
+ #
# Readline
#

***************
*** 6490,6504 ****

if test "$with_readline" = yes; then

- echo "$as_me:$LINENO: checking for readline" >&5
- echo $ECHO_N "checking for readline... $ECHO_C" >&6

if test "${pgac_cv_check_readline+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
cat >conftest.$ac_ext <<_ACEOF
--- 6522,6540 ----

if test "$with_readline" = yes; then

if test "${pgac_cv_check_readline+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! if test x"$with_libedit_preferred" != x"yes"
! then READLINE_ORDER="-lreadline -ledit"
! else READLINE_ORDER="-ledit -lreadline"
! fi
! for pgac_rllib in $READLINE_ORDER ; do
! echo "$as_me:$LINENO: checking for ${pgac_rllib}" >&5
! echo $ECHO_N "checking for ${pgac_rllib}... $ECHO_C" >&6
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
cat >conftest.$ac_ext <<_ACEOF
***************
*** 6557,6563 ****
esac

pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
! break 2

else
echo "$as_me: failed program was:" >&5
--- 6593,6599 ----
esac

pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
! break

else
echo "$as_me: failed program was:" >&5
***************
*** 6567,6590 ****
rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
done
done
LIBS=$pgac_save_LIBS

fi

if test "$pgac_cv_check_readline" != no ; then

cat >>confdefs.h <<\_ACEOF
#define HAVE_LIBREADLINE 1
_ACEOF

-   LIBS="$pgac_cv_check_readline $LIBS"
-   echo "$as_me:$LINENO: result: yes ($pgac_cv_check_readline)" >&5
- echo "${ECHO_T}yes ($pgac_cv_check_readline)" >&6
- else
-   echo "$as_me:$LINENO: result: no" >&5
- echo "${ECHO_T}no" >&6
fi
if test x"$pgac_cv_check_readline" = x"no"; then
{ { echo "$as_me:$LINENO: error: readline library not found
If you have readline already installed, see config.log for details on the
--- 6603,6631 ----
rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
done
+   if test "$pgac_cv_check_readline" != no ; then
+     echo "$as_me:$LINENO: result: yes ($pgac_cv_check_readline)" >&5
+ echo "${ECHO_T}yes ($pgac_cv_check_readline)" >&6
+     break
+   else
+     echo "$as_me:$LINENO: result: no" >&5
+ echo "${ECHO_T}no" >&6
+   fi
done
LIBS=$pgac_save_LIBS

fi

if test "$pgac_cv_check_readline" != no ; then
+ LIBS="$pgac_cv_check_readline $LIBS"

cat >>confdefs.h <<\_ACEOF
#define HAVE_LIBREADLINE 1
_ACEOF

fi
+ 
+ 
if test x"$pgac_cv_check_readline" = x"no"; then
{ { echo "$as_me:$LINENO: error: readline library not found
If you have readline already installed, see config.log for details on the
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.432
diff -c -c -r1.432 configure.in
*** configure.in	5 Nov 2005 16:42:01 -0000	1.432
--- configure.in	3 Dec 2005 15:25:45 -0000
***************
*** 468,477 ****

#
# Readline
#
PGAC_ARG_BOOL(with, readline, yes,
!               [  --without-readline      do not use Readline])
# readline on MinGW has problems with backslashes in psql and other bugs.
# This is particularly a problem with non-US code pages.
# Therefore disable its use until we understand the cause. 2004-07-20
--- 468,484 ----

#
+ # Prefer libedit
+ #
+ PGAC_ARG_BOOL(with, libedit-preferred, no,
+               [  --with-libedit-preferred  prefer BSD Libedit over GNU Readline])
+ 
+ 
+ #
# Readline
#
PGAC_ARG_BOOL(with, readline, yes,
!               [  --without-readline      do not use GNU Readline / BSD Libedit line editing])
# readline on MinGW has problems with backslashes in psql and other bugs.
# This is particularly a problem with non-US code pages.
# Therefore disable its use until we understand the cause. 2004-07-20
Index: config/programs.m4
===================================================================
RCS file: /cvsroot/pgsql/config/programs.m4,v
retrieving revision 1.18
diff -c -c -r1.18 programs.m4
*** config/programs.m4	2 Dec 2004 20:04:19 -0000	1.18
--- config/programs.m4	3 Dec 2005 15:25:47 -0000
***************
*** 78,89 ****

AC_DEFUN([PGAC_CHECK_READLINE],
[AC_REQUIRE([AC_CANONICAL_HOST])
- AC_MSG_CHECKING([for readline])

AC_CACHE_VAL([pgac_cv_check_readline],
[pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
AC_TRY_LINK_FUNC([readline], [[
--- 78,93 ----

AC_DEFUN([PGAC_CHECK_READLINE],
[AC_REQUIRE([AC_CANONICAL_HOST])

AC_CACHE_VAL([pgac_cv_check_readline],
[pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! if test x"$with_libedit_preferred" != x"yes"
! then READLINE_ORDER="-lreadline -ledit"
! else READLINE_ORDER="-ledit -lreadline"
! fi
! for pgac_rllib in $READLINE_ORDER ; do
! AC_MSG_CHECKING([for ${pgac_rllib}])
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
AC_TRY_LINK_FUNC([readline], [[
***************
*** 98,117 ****
esac

pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
! break 2
]])
done
done
LIBS=$pgac_save_LIBS
])[]dnl AC_CACHE_VAL

if test "$pgac_cv_check_readline" != no ; then
- AC_DEFINE(HAVE_LIBREADLINE, 1, [Define if you have a function readline library])
LIBS="$pgac_cv_check_readline $LIBS"
! AC_MSG_RESULT([yes ($pgac_cv_check_readline)])
! else
! AC_MSG_RESULT(no)
! fi])# PGAC_CHECK_READLINE

--- 102,126 ----
esac

pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
!       break
]])
done
+   if test "$pgac_cv_check_readline" != no ; then
+     AC_MSG_RESULT([yes ($pgac_cv_check_readline)])
+     break
+   else
+     AC_MSG_RESULT(no)
+   fi
done
LIBS=$pgac_save_LIBS
])[]dnl AC_CACHE_VAL

if test "$pgac_cv_check_readline" != no ; then
LIBS="$pgac_cv_check_readline $LIBS"
! AC_DEFINE(HAVE_LIBREADLINE, 1, [Define if you have a function readline library])
! fi
!
! ])# PGAC_CHECK_READLINE

Index: doc/src/sgml/installation.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.249
diff -c -c -r1.249 installation.sgml
*** doc/src/sgml/installation.sgml	5 Nov 2005 00:04:04 -0000	1.249
--- doc/src/sgml/installation.sgml	3 Dec 2005 15:25:49 -0000
***************
*** 50,56 ****
<para>
In general, a modern Unix-compatible platform should be able to run
<productname>PostgreSQL</>.
!     The platforms that had received specific testing at the
time of release are listed in <xref linkend="supported-platforms">
below. In the <filename>doc</> subdirectory of the distribution
there are several platform-specific <acronym>FAQ</> documents you
--- 50,56 ----
<para>
In general, a modern Unix-compatible platform should be able to run
<productname>PostgreSQL</>.
!    The platforms that had received specific testing at the
time of release are listed in <xref linkend="supported-platforms">
below. In the <filename>doc</> subdirectory of the distribution
there are several platform-specific <acronym>FAQ</> documents you
***************
*** 107,122 ****
</indexterm>

The <acronym>GNU</> <productname>Readline</> library (for
! comfortable line editing and command history retrieval) will be
! used by default. If you don't want to use it then you must
! specify the <option>--without-readline</option> option for
! <filename>configure</>. (On <productname>NetBSD</productname>,
! the <filename>libedit</filename> library is
! <productname>Readline</productname>-compatible and is used if
! <filename>libreadline</filename> is not found.) If you are using
! a package-based Linux distribution, be aware that you need both
! the <literal>readline</> and <literal>readline-devel</> packages,
! if those are separate in your distribution.
</para>
</listitem>

--- 107,126 ----
</indexterm>

The <acronym>GNU</> <productname>Readline</> library (for
! simple line editing and command history retrieval) is
! used by default. If you don't want to use it then you must specify
! the <option>--without-readline</option> option for
! <filename>configure</>. As an alternative, you can often use the
! BSD-licensed <filename>libedit</filename> library, originally
! developed on <productname>NetBSD</productname>. The
! <filename>libedit</filename> library is
! GNU <productname>Readline</productname>-compatible and is used if
! <filename>libreadline</filename> is not found, or if
! <option>--with-libedit-preferred</option> is used as an
! option to <filename>configure</>. If you are using a package-based
! Linux distribution, be aware that you need both the
! <literal>readline</> and <literal>readline-devel</> packages, if
! those are separate in your distribution.
</para>
</listitem>

***************
*** 858,863 ****
--- 862,877 ----
</varlistentry>

<varlistentry>
+        <term><option>--with-libedit-preferred</option></term>
+        <listitem>
+         <para>
+          Favors the use of the BSD-licensed <application>libedit</> library
+          rather than GPL-licensed <application>Readline</>.
+         </para>
+        </listitem>
+       </varlistentry>
+ 
+       <varlistentry>
<term><option>--without-readline</option></term>
<listitem>
<para>

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073