[GRASSLIST:6683] Re: libgrass as TGZ package

[Markus Neteler]

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

Yes.
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
	$prefix/lib/gdalplugins now.

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
     0
Correct value.

Do you get this number of GRASS libs?:
 ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
      6


> Do I need to re-install GDAL after having configured, built and installed 
> the plugin (I think not)?

No.

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

http://xserve.flids.com/pipermail/gdal-dev/2005-March/008227.html
"It is documented deep in the api ref docs at:
  http://www.gdal.org/classGDALDriverManager.html#a8
"

Good luck!

 Markus