On Sat, Aug 28, 2010 at 8:56 PM, William McCoy <[email protected]> wrote: > At the suggestion of Roger Bivand, I am moving this issue from r-sig-geo. > > I am using spgrass6, but I can't seem to initiate a grass session. I > managed to do this correctly months ago, but can't seem to now. Here > is my code and sessionInfo: > >> library(spgrass6) > > Loading required package: sp > Loading required package: rgdal > Geospatial Data Abstraction Library extensions to R successfully > loaded > Loaded GDAL runtime: GDAL 1.7.2, released 2010/04/23 > Path to GDAL shared files: /usr/local/share/gdal > Loaded PROJ.4 runtime: Rel. 4.7.1, 23 September 2009 > Path to PROJ.4 shared files: (autodetected) > Loading required package: XML > GRASS GIS interface loaded with GRASS version: (GRASS not running) >> >> loc <- initGRASS(gisBase = "/usr/local/grass-6.4.0svn/", home = >> tempdir()) > > g.gisenv: symbol lookup error: g.gisenv: undefined symbol: > G__no_gisinit > g.gisenv: symbol lookup error: g.gisenv: undefined symbol: > G__no_gisinit > g.gisenv: symbol lookup error: g.gisenv: undefined symbol: > G__no_gisinit > g.gisenv: symbol lookup error: g.gisenv: undefined symbol: > G__no_gisinit > g.gisenv: symbol lookup error: g.gisenv: undefined symbol: > G__no_gisinit > g.region: symbol lookup error: g.region: undefined symbol: G__gisinit > Error in if (file.exists(file) == FALSE) if (!missing(asText) && > asText == : > argument is of length zero > Error in parseGRASS(cmd) : g.region not parsed > >> sessionInfo() > > R version 2.11.1 (2010-05-31) > i386-redhat-linux-gnu
I have checked the archives and found this interesting email which might explain what happens: On Thu, Aug 14, 2008 at 6:37 AM, Glynn Clements <[email protected]> wrote: > G. Allegri wrote: > >> I understand that everything that needs GRASS has to be recompiled if >> this version changes so much to change its interface (QGis-GRASS >> plugin, GRASS-GDAL plugin, etc.). But I would like to know why the new >> develbrunch_6 revision needs the GDAL itself to be recompiled. I can >> understand it if GRASS would need a newer version of GDAL... is this >> the case? > > You only need to re-compile GDAL itself if GDAL was built with GRASS > support (--with-grass). > > In your original message, you wrote: > >> Even switching to develbrunch I receive the same error: >> usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit' > > This indicates that your GDAL library was indeed built --with-grass. I > suggest building it without that option, and using the GDAL-GRASS > plugin instead. > > If you build GDAL -with-grass, you will need to re-compile GDAL every > time that GRASS is updated from now on. The problem arises from > r32695, which makes G_gisinit() check that libgis was built with the > same version of gis.h as the caller. > > The change adds G_gisinit() and G_no_gisinit() macros: > > #define GIS_H_VERSION "$Revision: 32726 $" > > #define G_gisinit(pgm) G__gisinit(GIS_H_VERSION, (pgm)) > #define G_no_gisinit() G__no_gisinit(GIS_H_VERSION) > > The value of GIS_H_VERSION is automatically updated to the SVN > revision whenever gis.h is updated. > > The change also renames the functions to G__gisinit() and > G__no_gisinit() (which is why you get the "undefined reference" error > when using an old GDAL with a new libgis), and adds version checks: > > int G__gisinit(const char *version, const char *pgm) > { > ... > if (strcmp(version, GIS_H_VERSION) != 0) > G_fatal_error(_("Incompatible library version for module")); > > Any code which uses G_gisinit() or G_no_gisinit() passes the version > of gis.h with which it was compiled to the library functions, which > check that the same version of gis.h was used to compile the library. > > The rationale is to avoid having to track down subtle errors caused by > version incompatibilities between libgis and any code which uses it. > Now, if there is an incompatibility, you get a very unsubtle error > telling you that there's an incompatibility. > > -- > Glynn Clements <[email protected]> > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user In essence, you would need to check how old your GDAL installation is. Markus _______________________________________________ grass-stats mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-stats
