On 08/28/2010 07:24 PM, Markus Neteler wrote:
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

Markus,

This is interesting. I had configured gdal 1.7.2 --without grass and built it in July. I had then built grass pointing to the new gdal-config on the same day. Lastly, I configured and installed gdal-grass 1.4.2, again on the same day.

So I think I had done these things in the right order before I first had the problem with initGRASS() yesterday. After, I noticed that problem, I did 'svn up' and brought grass64svn up to date. I rebuilt and reinstalled it, but I didn't reconfigure and rebuild gdal-grass.

So just now, I did 'make distclean' in the gdal-grass directory and then reconfigured, rebuilt, and reinstalled gdal-grass. I then also removed spgrass6 and rgdal from my R libraries and then rebuilt and reinstalled both of them.

And now when I use initGRASS, I have exactly the same problem:


R version 2.11.1 (2010-05-31)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> Sys.getenv("LD_LIBRARY_PATH")


  LD_LIBRARY_PATH
"/usr/lib/R/lib:/usr/local/lib:/usr/lib/jvm/jre/lib/i386/server:/usr/lib/jvm/jre/lib/i386:/usr/lib/jvm/java/lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib"
> Sys.getenv("PATH")


                                              PATH
"/usr/local/texlive/2009/bin/i386-linux:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/wdmccoy/bin"
> 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
> Sys.getenv("LD_LIBRARY_PATH")


                                LD_LIBRARY_PATH
"/usr/lib/R/lib:/usr/local/lib:/usr/lib/jvm/jre/lib/i386/server:/usr/lib/jvm/jre/lib/i386:/usr/lib/jvm/java/lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib:/usr/local/grass-6.4.0svn/lib"
> Sys.getenv("PATH")



                                       PATH
"/usr/local/texlive/2009/bin/i386-linux:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/wdmccoy/bin:/usr/local/grass-6.4.0svn/bin:/usr/local/grass-6.4.0svn/scripts"


Note that initGRASS() does add the grass-6.4.0svn directories to PATH and LD_LIBRARY_PATH. But it still fails at the same point.

Any other ideas?

Thanks for your help.

Bill


--
William D. McCoy
Geosciences
University of Massachusetts
Amherst, MA 01003
_______________________________________________
grass-stats mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-stats

Reply via email to