Build problem on terminfo.c on FreeBSD 4.7

Build problem on terminfo.c on FreeBSD 4.7

[Felix Rosencrantz]

Since Clint's changes (zsh-workers/19076) I'm seeing build problems with
terminfo.c on FreeBSD 4.7:

terminfo.c: In function `boot_':
terminfo.c:381: warning: implicit declaration of function `setupterm'
terminfo.c:381: `ERR' undeclared (first use in this function)
terminfo.c:381: (Each undeclared identifier is reported only once
terminfo.c:381: for each function it appears in.)

ERR is defined in curses.h.  Not sure why that is not included, because the
autoconf code is opaque to me.

-FR.
ps mail archive URL: http://www.zsh.org/mla/workers/2003/msg00700.html

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Re: Build problem on terminfo.c on FreeBSD 4.7

[Oliver Kiddle]

On 2 Nov, Felix Rosencrantz wrote:
> Since Clint's changes (zsh-workers/19076) I'm seeing build problems with
> terminfo.c on FreeBSD 4.7:
> 
> terminfo.c: In function `boot_':
> terminfo.c:381: warning: implicit declaration of function `setupterm'
> terminfo.c:381: `ERR' undeclared (first use in this function)
> terminfo.c:381: (Each undeclared identifier is reported only once
> terminfo.c:381: for each function it appears in.)
> 
> ERR is defined in curses.h.  Not sure why that is not included, because the
> autoconf code is opaque to me.

I get this same problem on one particular Linux box. With
--with-curses-terminfo, it builds. Unfortunately, the autoconf code for
handling curses/terminfo is fairly opaque to me too.

At the top of terminfo.c, the following is used around the curses.h
include:

# ifdef HAVE_CURSES_H
#  include <curses.h>
# endif

So curses.h would be included. However, HAVE_CURSES_H is not defined.
This seems to be because the curses.h header check is inside this in
zshconfig.ac:
  case "$LIBS" in
  *curses*)
This presumably fails because it uses just -ltermcap.

libtermcap.so is just a link to libncurses.so here. So how is that
situation otherwise handled? Should the HAVE_SETUPTERM test perhaps
similarly only be done if $LIBS = *curses*? Or can we perhaps safely
substitute -1 for ERR?

Oliver

Re: Build problem on terminfo.c on FreeBSD 4.7

[Peter Stephenson]

Oliver Kiddle wrote:
> # ifdef HAVE_CURSES_H
> #  include <curses.h>
> # endif
> 
> So curses.h would be included. However, HAVE_CURSES_H is not defined.
> This seems to be because the curses.h header check is inside this in
> zshconfig.ac:
>   case "$LIBS" in
>   *curses*)
> This presumably fails because it uses just -ltermcap.
> 
> libtermcap.so is just a link to libncurses.so here. So how is that
> situation otherwise handled? Should the HAVE_SETUPTERM test perhaps
> similarly only be done if $LIBS = *curses*? Or can we perhaps safely
> substitute -1 for ERR?

The original idea seemed to be the terminfo module was restricted to
systems which used terminfo, which was taken to imply curses.  However,
it doesn't seem to have been taken into account everywhere, and I think
the distinction is all a bit historical now.  In particular, on many
systems (like this one) termcap if it exists seems to be a vague pointer
to curses anyway, so deliberately linking against -ltermcap is
pointless.  What's more, on some other systems termcap is only
statically linked (possiably with hacked-out bits of curses, though I
don't know that) while curses, with the same symbols and more, is
dynamic.

In short, it's a mess.

Here, if curses is actually being used, whether in disguise or not, I
think we have two choices (1) continue to use the logic that applies to
termcap, i.e. not provide the functionality for terminfo (2) apply *all*
the definitions that refer to curses, including any applicable HAVE_*
stuff, changing configure as necessary.  I don't think propagating a
hybrid is a good idea.

More generally, I think the thing to do is only compile a stub terminfo
unless everything necessary is around (subject to the complications
above of what this actually means).  Probably even better would be not
to attempt to compile it; this can be done with a suitable test (which
might not be trivial, however) in the .mdd file.  On my Linux system,
the library is present but echoti simply says `not available on this
system'.  We could only compile the library at all on systems where we
know it's going to work.

There have been endless problems of this sort.  I'd *really* like to get
this sorted out before 4.1 becomes 4.2.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk