unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: vuori@notcom.org
Cc: 64577@debbugs.gnu.org
Subject: bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library
Date: Wed, 12 Jul 2023 15:11:02 +0300	[thread overview]
Message-ID: <837cr572jt.fsf@gnu.org> (raw)
In-Reply-To: <87v8eqrxq8.fsf@notcom.org> (vuori@notcom.org)

> From: vuori@notcom.org
> Date: Tue, 11 Jul 2023 20:37:19 +0000
> 
> 
> configure on NetBSD forces using the native libterminfo library, even
> when ncurses is available. When started with a TERM such xterm-256color,
> this results in abort() in tputs1 (TERM=xterm works).
> 
> Hacking configure to use ncurses when available provides stable
> operation on xterm-256color.
> 
> The current special configure logic originates from this issue:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6190 . This check is
> probably not a good idea today. Either NetBSD should do a) what the
> other BSDs do (= force ncurses) or b) what gnu* does (use what
> configure found, otherwise force ncurses).
> 
> My vote goes to b (possibly with a warning from configure if libterminfo
> is picked): keep it possible to build emacs without installing ncurses,
> but use ncurses for terminfo when available.

I'm not sure I understand.  The configure script first looks for a
library with tputs, and it tries tinfo, ncurses, terminfo, curses,
termcap, tinfow, ncursesw, in that order.  I understand that in your
case it finds ncurses, which is good, right?

After that, the configure script decides whether to use terminfo or
termcap.  It is here that for netbsd we decide to use termcap in
certain situations instead of terminfo.  In your case, since ncurses
was found, LIBS_TERMCAP should have been set to -lncurses, and this
code:

  netbsd)
    if test "x$LIBS_TERMCAP" != "x-lterminfo"; then
      TERMINFO=no
      LIBS_TERMCAP="-ltermcap"
    fi

should have set TERMINFO=no, which disables linking against terminfo.

So I don't think I understand what is going on there.

As I don't have access to a netbsd system, could you please post the
config.log you get when configuring with a fresh tree of
emacs-29.0.92, and also show the "set -x" expansion of the relevant
parts of the configure script?  (Please compress those when posting if
they are larger than, say, 0.5MB.)  I would like to use those to
understand what happens on your system and why the configure script
decides to use terminfo.

Once we understand the exact reason, it will be easier to discuss
potential solutions.

Also, do you happen to know when terminfo on NetBSD started to be
buggy?  I would think that the change in bug#6190 did work at the
time, so at least back then NetBSD did have a workable terminfo.  When
did it start failing?

Thanks.





  reply	other threads:[~2023-07-12 12:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 20:37 bug#64577: 29.0.92; configure on NetBSD forces unstable terminfo library vuori
2023-07-12 12:11 ` Eli Zaretskii [this message]
2023-07-12 12:57   ` Valtteri Vuorikoski
2023-07-12 13:32     ` Eli Zaretskii
2023-07-12 14:06       ` Valtteri Vuorikoski
2023-07-12 16:06         ` Eli Zaretskii
2023-07-12 20:22           ` Valtteri Vuorikoski
2023-07-13  5:19             ` Eli Zaretskii
2023-07-13  9:35               ` Valtteri Vuorikoski
2023-07-15  8:17                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837cr572jt.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=64577@debbugs.gnu.org \
    --cc=vuori@notcom.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).