[GRASS5] Re: TERMLIB [GRASSLIST:4597]

Glynn Clements glynn.clements at virgin.net
Tue Oct 1 14:41:24 EDT 2002


Glynn Clements wrote:

> Christian Riedler wrote:
> 
> > I'm new to Linux and GRASS and I have following problem.
> > I downloaded and installed GRASS at my LINUX computer (Suse Linux 7.0).
> > When I try to start GRASS an error occurs with following error message:
> > /usr/lical/grass5/etc/set_data: error in loading shared libraries:
> > libtermap.so.2: cannot open shared object file: no such file or directory
> 
> Either you need to install an appropriate package (on RedHat 6.2,
> libtermcap.so.2 is in its own package, called "libtermcap"), or the
> pre-compiled binaries aren't compatible with your Linux distribution.

Having looked into this further, I'm pretty certain that this
dependency is bogus. I.e. set_data (and GRASS generally) will work
fine without this library.

The configure script explicitly checks for a library which provides
tgetent(), but nothing actualy uses this function directly. The curses
library *might* use it, but OTOH:

1. It might not; newer versions of curses typically won't.

2. It might provide the function itself; curses implementations often
have the termcap and/or terminfo functionality "bundled" into the main
curses library.

3. Even if tgetent() is used, it might be provided by a library other
than the one which configure actually selects. E.g. on my system, both
libtermcap and libtinfo provide tgetent() functions; configure will
select libtermcap, but libncurses is actually linked against libtinfo.

4. Even if the curses library does require additional libraries, a
shared curses library will normally have dependency information, which
ensures that the correct libraries are linked in automatically. Also,
if this isn't the case, then the configure checks for the curses
library would fail anyway.

The situation is complicated further by a requirement that gtty() be
available somewhere, even though it isn't actually required; wherever
gtty()/stty() are used, the code can use either ioctl(TCGETA/TCSETA)
or tcgetattr()/tcsetattr() instead.

The current situation is that configure.in has:

	AC_CHECK_LIB(ncurses, initscr, CURSESLIB=-lncurses, [
	AC_CHECK_LIB(curses, initscr, CURSESLIB=-lcurses, [
	    AC_MSG_ERROR([*** Unable to locate curses library.])
	    CURSESLIB=
	])])
	AC_SUBST(CURSESLIB)

	AC_CHECK_LIB(compat, gtty, COMPATLIB=-lcompat, [
	AC_CHECK_LIB(bsd-compat, gtty, COMPATLIB=-lbsd-compat, [
	AC_CHECK_LIB(bsd, gtty, COMPATLIB=-lbsd, [
	    COMPATLIB=
	])])])
	AC_SUBST(COMPATLIB)

	AC_CHECK_LIB(termlib, tgetent, TERMLIB=-ltermlib, [
	AC_CHECK_LIB(termcap, tgetent, TERMLIB=-ltermcap, [
	AC_CHECK_LIB(ncurses, tgetent, TERMLIB=-lncurses, [
	AC_CHECK_LIB(curses, tgetent, TERMLIB=-lcurses, [
	    AC_MSG_WARN([*** Unable to locate tgetent() function.])
	    TERMLIB=
	])])])])
	AC_SUBST(TERMLIB)

and src/CMD/head/head.in has:

	COMPATLIB           = @COMPATLIB@
	TERMLIB             = @TERMLIB@
	CURSES              = @CURSESLIB@ $(TERMLIB) $(COMPATLIB)

Thus, we are introducing dependencies which are unnecessary.

A more sensible approach would be:

1. Check for one of the pairs:

a) tcgetattr()/tcsetattr()
b) ioctl(TCGETA)/ioctl(TCSETA)
c) gtty()/stty()

without any additional libraries (although I'm not sure how to make
autoconf handle b)).

2. If we can't find any of the above, then try to get c) from
lib{compat,bsd,bsd-compat}, and define COMPATLIB accordingly.

3. Check for curses without any additional libraries. Note that this
is all that we do at present, and I don't recall any reports of the
check failing due to a requirement for additional libraries.

4. If 3 doesn't suffice, start iterating through the combinations of
$COMPATLIB, libtinfo, libtermcap and libtermlib.

The main issue is how much of this (if any) to do for 5.0.1. I suggest
at least killing the TERMLIB check, i.e. changing it to:

	TERMLIB=
	AC_SUBST(TERMLIB)

as the current situation is resulting in curses clients (including
set_data) failing to run on some systems for no good reason. 

Additionally, it could conceivably result in curses using the wrong
tgetent(), e.g. using the termcap version rather than terminfo. [As I
write this, it has just occured to me that this could be related to
the MacOSX problems.]

-- 
Glynn Clements <glynn.clements at virgin.net>




More information about the grass-dev mailing list