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

Hi developers,

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) ;

But:
find . -name "*.c" |xargs fgrep --files-with-match stdscr |\
                    xargs fgrep --files-without-match curses.h
./V_exit.c
./V_call.c
./V_init.c

Can this be the problem? However, in vask.h it is included.
Means, that it is included twice in V_support.c, a problem?

Markus

On Fri, 2006-12-01 at 10:26 +0100, Markus Neteler wrote:

Hi developers,

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) ;

But:
find . -name "*.c" |xargs fgrep --files-with-match stdscr |\
                    xargs fgrep --files-without-match curses.h
./V_exit.c
./V_call.c
./V_init.c

Can this be the problem? However, in vask.h it is included.
Means, that it is included twice in V_support.c, a problem?

I move <grass/config.h> to the top of V_support.c and added it to
another file that was missing it. I also added a macro around
<grass/vask.h> to prevent multiple inclusion. Updated documentation,
also.

The files could probably use some #ifdef HAVE_CURSES_H macros...
Let me know if it's still broke and I'll add the above macro where
needed.

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

Markus Neteler 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.

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

Brad Douglas wrote:

The files could probably use some #ifdef HAVE_CURSES_H macros...

In most cases, there isn't much point conditionalising inside source
files. Most of the code which uses curses absolutely requires it, and
can't do anything without it.

If anything, vask, and everything which requires it, should be
conditionalised in the Makefiles. If you don't have curses, vask
doesn't get built, and modules which require it don't get built.

The main complication is the imagery library. Parts of it require
vask; they would need to be conditionalised individually rather than
omitting the entire library if curses isn't available.

That could by done either by listing the individual object files in
lib/imagery/Makefile, with the vask-dependent ones conditionalised, or
by bracketing the bodies of the source files with "#ifdef HAVE_CURSES_H".

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

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@gclements.plus.com>

Glynn Clements wrote:

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 ...

I've eliminated the vask dependency for lib/imagery.

Now, the only things which should require curses are those which
actually use it, primarily those which use the vask (i.ortho.photo,
i.class, etc/set_data, r.le.setup, r.support, v.transform) or edit
(etc/set_data, r.support) libraries, although a couple of modules use
curses directly (e.g. d.colors, i.vpoints).

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