Thread: BUG #2674: libedit not detected
The following bug has been logged online: Bug reference: 2674 Logged by: Bob Friesenhahn Email address: bfriesen@simple.dallas.tx.us PostgreSQL version: 8.1.4 Operating system: Apple OS X Description: libedit not detected Details: After carefully removing all traces of GNU readline from the system, libedit-20060829-2.9 was installed to /usr/local. Configure was executed like: LDFLAGS=-L/usr/local/lib ./configure '--prefix=/opt/foo/postgresql' '--with-openssl' '--enable-thread-safety' '--with-pam' '--with-python' '--enable-integer-datetimes' The configure run terminates with: checking editline/readline.h usability... yes checking editline/readline.h presence... yes checking for editline/readline.h... yes checking editline/history.h usability... no checking editline/history.h presence... no checking for editline/history.h... no checking history.h usability... no checking history.h presence... no checking for history.h... no checking readline/history.h usability... no checking readline/history.h presence... no checking for readline/history.h... no configure: error: history header not found If you have libedit already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable libedit support. The libedit package does not provide a history.h header file. It is valuable for PostgreSQL to support libedit since it is BSD licensed while GNU readline is GPL licensed.
"Bob Friesenhahn" <bfriesen@simple.dallas.tx.us> writes:
> libedit-20060829-2.9 was installed to /usr/local.
> Configure was executed like:
> LDFLAGS=-L/usr/local/lib ./configure '--prefix=/opt/foo/postgresql'
> '--with-openssl' '--enable-thread-safety' '--with-pam' '--with-python'
> '--enable-integer-datetimes'
> configure: error: history header not found
Apparently your compiler doesn't search /usr/local/include by default.
The recommended way to do this is to
configure --with-includes=/usr/local/include --with-libs=/usr/local/lib
rather than fooling with LDFLAGS or CPPFLAGS directly.
regards, tom lane
Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes: > Actually, it does. The current version of libedit > (http://www.thrysoee.dk/editline/) does not provide a history.h > header. Well, that was a pretty silly decision on their part ... are they just trying to tick off people who are supporting both readline and libedit? > The reason why I used this approach is that Apple's OS X > provides a version of libedit which does not include the readline > emulation Really? Apple's version works just fine for me. regards, tom lane
Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes:
>> Really? Apple's version works just fine for me.
> I am using the "Panther" version of OS X and there there is only a
> /usr/include/histedit.h there are no readline-related headers supplied
> with the OS and the emulation function does not exist in
> /usr/lib/libedit.dylib:
Hmph ... I thought I'd built it successfully on 10.3.* too, but I don't
have any such installations around here anymore. Anyway, I've changed
CVS HEAD's configure to not look for history.h when libedit is being
used. We'll see how well that works ...
regards, tom lane
On Wed, 4 Oct 2006, Tom Lane wrote: > "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us> writes: >> libedit-20060829-2.9 was installed to /usr/local. > >> Configure was executed like: >> LDFLAGS=-L/usr/local/lib ./configure '--prefix=/opt/foo/postgresql' >> '--with-openssl' '--enable-thread-safety' '--with-pam' '--with-python' >> '--enable-integer-datetimes' > >> configure: error: history header not found > > Apparently your compiler doesn't search /usr/local/include by default. Actually, it does. The current version of libedit (http://www.thrysoee.dk/editline/) does not provide a history.h header. However, I created an empty history.h (/usr/local/include/editline/history.h) to fool configure and was able to get PostgreSQL working with libedit. When built with libedit, the PostgreSQL sources do not seem to actually use the history.h header. Due to the licensing issues, it would be very useful if the configure script provided a means to specify using libedit rather than libreadline. With the current approach, libreadline is automatically used if it exists. Libreadline always takes priority over libedit. I had to delete libreadline and its headers from my machine in order to use libedit. Of course this broke a number of installed applications. > The recommended way to do this is to > configure --with-includes=/usr/local/include --with-libs=/usr/local/lib > rather than fooling with LDFLAGS or CPPFLAGS directly. Ok, thanks. The reason why I used this approach is that Apple's OS X provides a version of libedit which does not include the readline emulation and Apple's GCC searches /usr/lib prior to /usr/local/lib by default. Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
On Wed, 4 Oct 2006, Tom Lane wrote: > Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes: >> Actually, it does. The current version of libedit >> (http://www.thrysoee.dk/editline/) does not provide a history.h >> header. > > Well, that was a pretty silly decision on their part ... are they just > trying to tick off people who are supporting both readline and libedit? Probably so. >> The reason why I used this approach is that Apple's OS X >> provides a version of libedit which does not include the readline >> emulation > > Really? Apple's version works just fine for me. I am using the "Panther" version of OS X and there there is only a /usr/include/histedit.h there are no readline-related headers supplied with the OS and the emulation function does not exist in /usr/lib/libedit.dylib: % nm /usr/lib/libedit.dylib |grep ' T ' 88e94d04 T _el_beep 88e943dc T _el_deletestr 88e946f8 T _el_end 88e94a38 T _el_get 88e97780 T _el_getc 88e97884 T _el_gets 88e945ec T _el_init 88e94330 T _el_insertstr 88e94b3c T _el_line 88e96e20 T _el_parse 88e975bc T _el_push 88e94780 T _el_reset 88e94c88 T _el_resize 88e947b4 T _el_set 88e94b44 T _el_source 88e9e858 T _history 88e9e058 T _history_end 88e9df9c T _history_init 88e9eca0 T _tok_end 88e9ebb8 T _tok_init 88e9ece8 T _tok_line 88e9ec80 T _tok_reset Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Bob Friesenhahn wrote: > On Wed, 4 Oct 2006, Tom Lane wrote: > > > "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us> writes: > >> libedit-20060829-2.9 was installed to /usr/local. > > > >> Configure was executed like: > >> LDFLAGS=-L/usr/local/lib ./configure '--prefix=/opt/foo/postgresql' > >> '--with-openssl' '--enable-thread-safety' '--with-pam' '--with-python' > >> '--enable-integer-datetimes' > > > >> configure: error: history header not found > > > > Apparently your compiler doesn't search /usr/local/include by default. > > Actually, it does. The current version of libedit > (http://www.thrysoee.dk/editline/) does not provide a history.h > header. However, I created an empty history.h > (/usr/local/include/editline/history.h) to fool configure and was able > to get PostgreSQL working with libedit. When built with libedit, the > PostgreSQL sources do not seem to actually use the history.h header. > > Due to the licensing issues, it would be very useful if the configure > script provided a means to specify using libedit rather than > libreadline. With the current approach, libreadline is automatically 8.2 will have configure --with-libedit-preferred. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Bob Friesenhahn wrote:
>> Due to the licensing issues, it would be very useful if the configure
>> script provided a means to specify using libedit rather than
>> libreadline. With the current approach, libreadline is automatically
> 8.2 will have configure --with-libedit-preferred.
Although it remains to be seen how many variants of libedit our code
actually works with :-(. Bob, please do try CVS tip if you haven't
already.
regards, tom lane