[GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC

[Glynn Clements]

Glynn Clements wrote:

> > I have seen this message in the GDAL list:
> > 
> > On Tue, Nov 28, 2006 at 11:03:00AM +1100, Craig Feuerherdt wrote:
> > ...
> > >    I am using Gentoo Linux.
> > ..
> > >    When I attempt to use ogrinfo I get the following errors:
> > > 
> > >    ogrinfo PGeo:b_pgeo
> > >    ERROR 1: /usr/grass-6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr
> > >    ERROR 1: /usr/grass- 6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr
> > >    Segmentation fault
> > > 
> > >    I can not work out why the error involves GRASS?
> > 
> > cd lib/vask/
> > grep stdscr *
> > V_call.c:       getyx (stdscr, y, x);
> > V_exit.c:       keypad(stdscr, 0);
> > V_init.c:    keypad(stdscr, 1);
> > V_support.c:    getyx(stdscr, cury, curx) ;
> 
> Note that most of the curses "functions" which don't begin with "w"
> are actually macros which call the corresponding function with
> "stdscr" as the target window, e.g.:
> 
> 	#define addch(ch)		waddch(stdscr,ch)
> 	#define addchnstr(str,n)	waddchnstr(stdscr,str,n)
> 	#define addchstr(str)		waddchstr(stdscr,str)
> 
> ... and so on.
> 
> My guess is that, in some curses implementations, stdscr might be a
> macro. A normal GRASS binary distribution wouldn't be compatible with
> such an implementation; you would need to re-compile GRASS.

Having thought about this some more, I'm more interested in how GDAL
ends up using the parts of GRASS which use the vask library.

...

I should have guessed; it's the imagery library:

	/* -------------------------------------------------------------------- */
	/*      Check if this is a valid GRASS imagery group.                   */
	/* -------------------------------------------------------------------- */
	    else {
	        struct Ref ref;
	
	        I_init_group_ref( &ref );
	        if ( I_get_group_ref( pszName, &ref ) == 0 ) {
		    free(pszGisdb); free(pszLoc); free(pszMapset); free(pszElem); free(pszName);
		    return NULL;
		}
	        
	        for( int iRef = 0; iRef < ref.nfiles; iRef++ ) 
		{
	            papszCells = CSLAddString( papszCells, ref.file[iRef].name );
	            papszMapsets = CSLAddString( papszMapsets, ref.file[iRef].mapset );
	            G_add_mapset_to_search_path ( ref.file[iRef].mapset );
	        }
	
	        I_free_group_ref( &ref );
	    }

Now, none of this involves vask, but because some parts of the imagery
library require it, the imagery library itself requires it.

AFAICT, the following files from lib/imagery actually use vask:

	file		used by
	
	ask_bands.c	<nothing>
	ask_colors.c	<nothing>
	tape_info.c	<nothing>
	v_exec.c	ask_bands.c, tape_info.c (both unused)
	vask_group.c	i.class

IOW, the only reason why the imagery library needs to use vask is
because i.class uses I_vask_subgroup_old(). In which case, that code
can be moved to i.class, leaving the vask and edit libraries as the
only libraries which uses curses.

More later ...

-- 
Glynn Clements <glynn at gclements.plus.com>