[GRASS5] curses, foiled again!

[Glynn Clements]

Roger Miller wrote:

> I've been trying to get Grass 5.3.0 to compile on a new SuSE 9.1 installation.  
> Most things are working well, however...
> 
> V_call.o in the vask library uses __waddbytes, which is defined in the curses 
> library, but not in the ncurses library.  The config routine specifies 
> -lncurses for everything that uses libvask.a, but it doesn't specify 
> -lcurses, which leaves __waddbytes undefined.
> 
> I can go through the (long and tedious) labor of recompiling each of the 
> failed modules manually, but I would rather find and fix the problem.  Where 
> and how would I look to fix this?

In all probability, the vask code is using the headers from one
version of curses but the programs which use it are being linked
against a library from a different version, and the two aren't
compatible.

Many of the curses "functions" which vask uses are actually actually
implemented as macros. FWIW, V_call.c uses the following curses
symbols:

	curscr
	stdscr
	addch
	addstr
	getch
	getyx
	move
	refresh
	wrefresh

On my system, these result in the following curses dependencies in
V_call.o:

	curscr
	stdscr
	waddch
	waddnstr
	wgetch
	wmove
	wrefresh

with the missing symbols corresponding to the following macros:

#define addch(ch)      		waddch(stdscr,ch)
#define addstr(str)    		waddnstr(stdscr,str,-1)
#define getch()        		wgetch(stdscr)
#define getyx(win,y,x)   	(y = (win)?(win)->_cury:ERR, x = (win)?(win)->_curx:ERR)
#define move(y,x)     		wmove(stdscr,y,x)
#define refresh()      		wrefresh(stdscr)

Presumably your curses.h defines one of these macros (probably addstr)
in terms of __waddbytes().

Essentially, you need to determine suitable settings for the
--with-includes= and/or --with-libs= configure switches such that the
compiler and linker will use a matching set of headers and library.

Note that the vask source code always refers to <curses.h>, but the
linker will use either -lncurses or -lcurses, depending upon which one
configure detects first (i.e. it will only use -lcurses if the check
fails for -lncurses).

One option is to create a temporary directory containing a symlink
named curses.h which refers to the ncurses version of the header, and
specify that via the --with-includes= switch.

Another option is to manually edit either src/CMD/head/head.<arch> or
mk/vars.mk (depending upon which build system is being used) and
change CURSES to use -lcurses instead of -lncurses.

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