Обсуждение: readline/libedit selection
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
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
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}"
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
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