[GRASSLIST:6683] Re: libgrass as TGZ package
neteler at itc.it
Fri Apr 29 12:57:25 EDT 2005
On Fri, Apr 29, 2005 at 06:31:20PM +0200, Roger Bivand wrote:
> On Fri, 29 Apr 2005, Markus Neteler wrote:
> > On Fri, Apr 29, 2005 at 02:45:21PM +0200, Roger Bivand wrote:
> > > On Fri, 29 Apr 2005, Markus Neteler wrote:
> > > > On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
> > ...
> > > > But the recommended method is to use the GDAL/GRASS
> > > > plugin. Compilation order:
> > > >
> > > > - GDAL without GRASS support (you may have to actively disable
> > > > it using the appropriate configure switches)
> > > > - GRASS 6
> > > > - GDAL/GRASS plugin
> > > >
> > > > Configure scripts can be grabbed here:
> > > > http://mpa.itc.it/markus/useful/index.html
> > > >
> > > > -> conf_gdal.sh
> > > > -> conf_grass61_linux.sh
> > > > -> conf_install_gdal_grass_plugin.sh
> > >
> > > Well, after having done this, and:
> > >
> > > $ ls -l /usr/local/lib/gdalplugins
> > > total 36
> > > -rwxr-xr-x 1 root root 34606 Apr 29 14:32 gdal_GRASS.so
> > >
> > > (the script presupposes that the user running it has access to
> > > gdalplugins)
> > Well, the plugin has to be installed along with GDAL. So
> > probably root permissions are needed.
> Yes, but then two scripts would be needed, one for ./configure and make,
> one for make install ...
I didn't intend to provide all-in-one solutions - moreover
the suggested scripts are an offer to figure out the parameters.
> > > I still can't see any access:
> > >
> > > $ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
> > > ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology'
> > > not recognised as a supported file format.
> > OK - a couple of tests:
> > - which GDAL version are you using? The search patch changed.
> > If you have an "older" GDAL, try to move the plugin to
> > /usr/local/lib/ (where libgdal.so stays)
> 1.2.6 from the tarball compiled 29 April, is this "older"?
The GDAL ChangeLog says:
2005-04-22 15:40 fwarmerdam
* frmts/grass/pkg/configure.in: Default for autoload path is
Do you have 1.2.6 or 1.2.6-CVS? 1.2.6 was released in March, so it's older.
The current CVS is using the new scheme.
> > - if this works, congrats (keep in mind that /usr/[local/]lib/gdalplugins
> > is the new home
> It doesn't work.
So you seem to have a "new" GDAL.
> > - if this doesn't work, move the gdal_GRASS.so back to
> > /usr/local/lib/gdalplugins/
> > - then
> > ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
> > Does it find the GRASS libraries? If not,
> No, it didn't find them.
OK, we are close:
> > - either add their path to /etc/ld.so.conf
> > - or link the GRASS libs into /usr/local/lib (this is what I do)
> I did this, ldd reports that they are present (after an ldconfig), but
> gdalinfo still doesn't recognise the file in cellhd (neither inside nor
> outside GRASS).
Here it will not (!) be listed as the plugin is loaded run-time:
ldd `which gdalinfo` | grep grass | wc -l
Do you get this number of GRASS libs?:
ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
> Do I need to re-install GDAL after having configured, built and installed
> the plugin (I think not)?
> I'm keeping on about this because if this is this difficult to configure
> for me, then the chances of any R/GRASS interface for GRASS 6 get very
> slim - there are so many hoops to jump though even on Unix/Linux (not to
> mention cygwin?) that no-one will ever use it.
> There do not seem to have been any downloads of the draft package from
> sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've no
I have added the link only last week to the GRASS site (unfortunately
no other developer did it). So probably nobody was aware of it.
I have downloaded it, so there must be at least 1 hit.
Testing forthcoming. In fact I'll need ot soon, so I'll spend
time on that.
> idea of whether any of this is actually required. GDAL and OGR provide
> ways to prototype the interface cleanly. But then GDAL has to work both
> ways, otherwise I can just stay with Arc ASCII grid files.
> What will help is a fool-proof installation route for getting r.out.gdal
> to work like v.out.ogr does
The "easy" solution is to write r.out.gdal in C. A long-standing wish...
> - I've no idea how the GDAL programs are
> supposed to find the plugin (I can understand that they know about formats
> they were compiled with, but how should a plugin be regisered in GDAL if
> is is built after GDAL itself?).
"It is documented deep in the api ref docs at:
More information about the grass-user