Postgres Pro
Downloads
Home   >   mailing lists

Thread: readline/libedit selection

readline/libedit selection

From
Kris Jurka
Date:
This recent change to readline/libedit selection isn't quite right.

http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php

It doesn't link in libtermcap with libedit which leads to:

checking for readline.h... no
configure: error: readline 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.

And in config.log:

configure:5987: gcc -o conftest -O2 -Wall -Wmissing-prototypes 
-Wpointer-arith -fno-strict-aliasing conftest.c -ledit -lcrypt -lresolv
-lcompat -lm -lutil >&5
/usr/lib/libedit.so: undefined reference to `tgetnum'
/usr/lib/libedit.so: undefined reference to `tgoto'
/usr/lib/libedit.so: undefined reference to `tgetflag'
/usr/lib/libedit.so: undefined reference to `tputs'
/usr/lib/libedit.so: undefined reference to `tgetent'
/usr/lib/libedit.so: undefined reference to `tgetstr'

This is on x86 NetBSD 1.6.

Kris Jurka

Re: readline/libedit selection

From
Tom Lane
Date:
Kris Jurka <books@ejurka.com> writes:
> This recent change to readline/libedit selection isn't quite right.

If you see a problem you'll have to give more details ...

> It doesn't link in libtermcap with libedit which leads to:

Certainly it tries that.

> checking for readline.h... no
> configure: error: readline header not found

This is a header failure, not a library failure.

> And in config.log:

> configure:5987: gcc -o conftest -O2 -Wall -Wmissing-prototypes 
> -Wpointer-arith -fno-strict-aliasing conftest.c -ledit -lcrypt -lresolv
> -lcompat -lm -lutil >&5
> /usr/lib/libedit.so: undefined reference to `tgetnum'
> /usr/lib/libedit.so: undefined reference to `tgoto'
> /usr/lib/libedit.so: undefined reference to `tgetflag'
> /usr/lib/libedit.so: undefined reference to `tputs'
> /usr/lib/libedit.so: undefined reference to `tgetent'
> /usr/lib/libedit.so: undefined reference to `tgetstr'

This would be expected at the first probe, but surely it's not the only
probe.

Reading between the lines, I wonder if your problem is that your copy of
editline puts its headers in include/readline rather than
include/editline?
        regards, tom lane

Re: readline/libedit selection

From
Tom Lane
Date:
Kris Jurka <books@ejurka.com> writes:
> This recent change to readline/libedit selection isn't quite right.
> http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php

I found the reason for not linking to libtermcap --- there was an
ancient netbsd-specific hack that wasn't general-purpose enough.
This wouldn't have anything to do with the header-file-not-found though.
        regards, tom lane

*** config/programs.m4.orig    Tue Nov 30 01:13:02 2004
--- config/programs.m4    Thu Dec  2 14:59:03 2004
***************
*** 87,99 ****   for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do     LIBS="${pgac_rllib}${pgac_lib}
$pgac_save_LIBS"    AC_TRY_LINK_FUNC([readline], [[
 
!       # NetBSD, OpenBSD, and Irix have a broken linker that does not
!       # recognize dependent libraries
!       case $host_os in netbsd* | openbsd* | irix*)
!         case $pgac_lib in
!           *curses*) ;;
!           *) pgac_lib=" -lcurses" ;;
!         esac       esac        pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
--- 87,100 ----   for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do     LIBS="${pgac_rllib}${pgac_lib}
$pgac_save_LIBS"    AC_TRY_LINK_FUNC([readline], [[
 
!       # Older NetBSD, OpenBSD, and Irix have a broken linker that does not
!       # recognize dependent libraries; assume curses is needed if we didn't
!       # find any dependency.
!       case $host_os in
!         netbsd* | openbsd* | irix*)
!           if test x"$pgac_lib" = x"" ; then
!             pgac_lib=" -lcurses"
!           fi ;;       esac        pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"

Re: readline/libedit selection

From
Kris Jurka
Date:

On Thu, 2 Dec 2004, Tom Lane wrote:

> Reading between the lines, I wonder if your problem is that your copy of
> editline puts its headers in include/readline rather than
> include/editline?
> 

Yes, this is the actual problem readline.h is indeed in 
/usr/include/readline..  The missing symbols I mentioned earlier 
are found in both libtermcap and libcurses, so I imagine linking to curses 
is still the correct thing to do.

Kris Jurka

Re: readline/libedit selection

From
Tom Lane
Date:
Kris Jurka <books@ejurka.com> writes:
> On Thu, 2 Dec 2004, Tom Lane wrote:
>> Reading between the lines, I wonder if your problem is that your copy of
>> editline puts its headers in include/readline rather than
>> include/editline?

> Yes, this is the actual problem readline.h is indeed in 
> /usr/include/readline.

Grumble ... they really shouldn't do that, because there's no sane
upgrade path to an installation of both libraries.  But I've hacked
configure to look there when trying to find libedit headers.
        regards, tom lane