bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library


From: Valtteri Vuorikoski
Subject: bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library
Date: Thu, 13 Jul 2023 12:35:51 +0300
User-agent: NeoMutt/20230517-193-0143df-dirty

On Thu, Jul 13, 2023 at 08:19:21AM +0300, Eli Zaretskii wrote:
> > The reason not much has been heard about this is probably that most
> > users likely use packaged emacs, and the pkgsrc build system forcibly sets
> > TERMINFO=yes if it determines that this is a NetBSD with the relevant
> > headers available. See this package build makefile:
> > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/emacs21/Makefile.common?rev=1.21&content-type=text/x-cvsweb-markup
> > "CPPFLAGS+=-DTERMINFO" (similarly check exists for emacsen up to 28).
> 
> If you could find out since when did the NetBSD pkgsrc system start
> using this override, it could be a data point that we could consider
> in making these decisions.

Looks like the TERMINFO override was installed in CVS version 1.7 in
May 2010 for emacs21:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/emacs21/Makefile.common?rev=1.7&content-type=text/x-cvsweb-markup

According to the comments, NetBSD 6.0 released the same year was the
first version to ship with libterminfo. From looking at the platform
repo, the old termcap library was completely removed in this release
and got replaced by the current libterminfo.

> > How about this then, this way should preserve the intent of the
> > original special casing while honoring the library selection configure
> > ended up with:
> > 
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -5212,9 +5212,8 @@ AC_DEFUN
> >      ;;
> > 
> >    netbsd)
> > -    if test "x$LIBS_TERMCAP" != "x-lterminfo"; then
> > +    if test "x$LIBS_TERMCAP" = "x-ltermcap"; then
> >        TERMINFO=no
> > -      LIBS_TERMCAP="-ltermcap"
> >      fi
> >      ;;
> > 
> > On ancient NetBSD (without ncurses) LIBS_TERMCAP should be detected as
> > -ltermcap, and this will ensure that TERMINFO stays undefined
> > (probably a no-op). On a newer system where someone actually wants to use
> > termcap and forces LIBS_TERMCAP, this will make sure that TERMINFO is
> > "no" even though libtermcap is a symlink to libterminfo (= only
> > the termcap compatibility functions will be used and terminfo stuff
> > will be ignored even though configure sees tputs() and friends).
> > 
> > The end result should be the same binary as pkgsrc packaging has
> > provided for years, except that on a system with ncurses installed
> > it will be used.
> 
> I don't mind installing the above instead of my proposal, thanks.

Great. I looked at NetBSD 5.1 sources and expanded the check somewhat:

--- a/configure.ac
+++ b/configure.ac
@@ -5212,7 +5212,11 @@ AC_DEFUN
     ;;

   netbsd)
-    if test "x$LIBS_TERMCAP" != "x-lterminfo"; then
+    # NetBSD versions prior to 6.0 lack native terminfo, but have a
+    # tputs() built on top of termcap in these libraries. Use native
+    # termcap instead in this case. NetBSD >= 6.0 has native terminfo
+    # implementation in -lterminfo.
+    if test "x$LIBS_TERMCAP" = "x-ltermcap" -o "x$LIBS_TERMCAP" = "x-lcurses"; 
then
       TERMINFO=no
       LIBS_TERMCAP="-ltermcap"
     fi

On 5.1 and older (no ncurses installed), configure's scan through
tputs_libraries matches either -ltermcap or -lcurses (both seem to
include tputs() in 5.1, but situation may differ in older versions),
but this will be termcap under the hood. Therefore force TERMINFO=no
and also force -ltermcap (as before) to avoid pulling in curses
unnecessarily.

On 6.0 and newer (again no ncurses) the order of tputs_libraries
should always cause -lterminfo to match first, so the branch will not
be taken and TERMINFO stays enabled.

Installing ncurses should now enable full terminfo support on any
version.

Tested on 9.3 with and without ncurses installed and the result is
full functionality with TERM=xterm-256color.

 -Valtteri
 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]