Al Davis:
> On Wed, 2 Feb 2022 18:52:55 +0100 (CET)
> [email protected] wrote:
> > If it just me, I'd just edit the files to suit my system.
>
> That's what I would do.
>
> In your case, it looks like the problem was that libtermcap was not
> installed properly. I link was missing.
I don't think so.
I think it is simply so that the distribution maintainers agree on
using ncurses instead of termcap, and the libtermcap is only provided
for legacy binary, 32bit, possible libc4 or libc5, type of programs.
Up to readline 2.1 there is a explicit -ltermcap in the Makefile.in
>From readline 2.2, you have a configure time choise between ncurses
(marked as preferred, which can provide the termcap api) or termcap.
Readline 2.2 is from 1998, and probably all linux dists. (my guess)
are using the ncurses choise.
The termcap api (small as it is) is provided by the ncurses and
no one else bothers to with writing thoose six functions and four
globals.
> > But your message makes me ask:
> >
> > 1, what systems should gnucap support, and how old ?
>
> I have no problem with omitting the test for termcap. That's easy.
I think that is the correct choise for current systems.
Simple patch attached.
> I think the real reason the test is there is to hide a problem with
> some systems that had a messed up installation of readline, which
> didn't work unless termcap was also installed. That was before the
> popularity of package systems like apt and yum, which keep track of
> things like that. So, the test for termcap should be dropped, because
> it is not explicitly used by gnucap. It was used implicitly through
> readline.
Even in old debian woody (2002-2005) libtermcap is simply a link to libncurses,
and termcap-compat is for libc5 binaries, no header files provided.
Debian hamm from 1998 is using the curses choise.
> As I recall, it was an issue on mostly BSD systems, which did all they
> could to avoid anything GNU.
NetBSD still has a different curses implementation, though they are
using terminfo now instead of termcap. Their gnucap package is old:
https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/cad/gnucap/
Their readline depend on libterminfo, not libtermcap.
...
> > 2, do you want to scrap gnucap configure scrips and use autotools
> > instead ?
...
> There was one time that gnucap (or its predecessor acs) did use
> autotools as the default build system. It turned out to be such a
...
Gentoo still uses gnucap from 2009 (that is a little surprising),
which seems to use autotools.
> One issue goes back to "I'd just edit the files...". In a practical
> sense, autotools takes away that option. The files are such a mess
> that "just edit the files" becomes impossible for those not in tune
> with autotools. Sometimes I think "just edit the files" is the best
> way. "Make" is really a nice programming language. Autotools takes it
> away, burying it under its own set of scripts and m4 macros.
Ack.
Regards,
/Karl Hammar
diff --git a/lib/configure b/lib/configure
index a10a76e..823ad5c 100755
--- a/lib/configure
+++ b/lib/configure
@@ -28,13 +28,13 @@ echo "CCFLAGS = -fPIC \\" >Make.ccflags
echo "LIBS = -ldl \\" >Make.libs
rm -f a.out
-c++ test_readline.cc -lreadline -ltermcap
+c++ test_readline.cc -lreadline
if [ -f a.out ] ; then
echo "using readline"
echo "-DHAVE_LIBREADLINE \\" >>Make.ccflags
- echo "-lreadline -ltermcap \\" >>Make.libs
+ echo "-lreadline \\" >>Make.libs
else
- echo "warning: either libtermcap or libreadline is missing - building without readline"
+ echo "warning: libreadline is missing - building without readline"
fi
rm -f a.out
