Opened 15 years ago

Closed 7 years ago

Last modified 6 years ago

#2953 closed enhancement (fixed)

Patch for GDAL-GRASS plugin for GRASS 7

Reported by: Markus Neteler Owned by: Even Rouault
Priority: normal Milestone: 2.1.3
Component: default Version: svn-trunk
Severity: normal Keywords: grass
Cc: wolf+grass@…, martinl, sbl

Description (last modified by sbl)

I have patched GDAL to compile against GRASS 7 (attached). However, the removal of the no longer existing libraries should be conditionalized to still permit the compilation against GRASS 6. I just dunno how to implement that (no autoconf guru).

Attachments (6)

gdal_grass7_plugin.diff (174.4 KB ) - added by Markus Neteler 15 years ago.
patch to compile GDAL-GRASS plugin against GRASS 7
patch_to_use_grass_config.patch (30.1 KB ) - added by wolf 13 years ago.
Patch to use grass-config from https://trac.osgeo.org/grass/ticket/596
patch-configure (784 bytes ) - added by hcho 10 years ago.
-lgrass_ccmath -lgrass_btree2
patch-configure.in (789 bytes ) - added by hcho 10 years ago.
-lgrass_ccmath -lgrass_btree2
frmts-grass-grass57dataset.cpp.patch (509 bytes ) - added by hcho 10 years ago.
Use Rast_get/set_window with GRASS 7.
Makefile.in.diff (1.5 KB ) - added by Markus Neteler 7 years ago.
Patch to not clone datum tables and drivers

Download all attachments as: .zip

Change History (63)

by Markus Neteler, 15 years ago

Attachment: gdal_grass7_plugin.diff added

patch to compile GDAL-GRASS plugin against GRASS 7

comment:1 by Even Rouault, 15 years ago

Owner: changed from warmerdam to Even Rouault

comment:2 by Even Rouault, 15 years ago

Resolution: fixed
Status: newclosed

In r16813 I've commited a version that enables building against GRASS 7 and older versions as well.

Grass enhancement request : it would be cool if GRASS had a grass-config script.

in reply to:  2 comment:3 by hamish, 14 years ago

Replying to rouault:

In r16813 I've commited a version that enables building against GRASS 7 and older versions as well.

is this still functional? ISTR we recently got a report that changes in grass trunk (7) had broken it.

Grass enhancement request : it would be cool if GRASS had a grass-config script.

here's the ticket for that wish:

https://trac.osgeo.org/grass/ticket/596

Hamish

comment:4 by Even Rouault, 14 years ago

r20157 /trunk/gdal/ (6 files in 3 dirs): Update GDAL and OGR GRASS drivers to compile against GRASS 7.0SVN (it compiles, but autotest gdrivers/grass.py and ogr/ogr_grass.py fail). Backward compatibility with GRASS 6.X preserved (#2953)

by wolf, 13 years ago

Patch to use grass-config from https://trac.osgeo.org/grass/ticket/596

comment:5 by wolf, 13 years ago

Cc: wolf+grass@… added

Added a patch to use grass-config from https://trac.osgeo.org/grass/ticket/596. Works on trunk.

comment:6 by dylan, 12 years ago

I have tried both patches to GDAL trunk (as of r23215) and neither can be applied cleanly (failed hunks). Is the strategy for getting GRASS7 support in GDAL enabled with the "--with-grass" flag when compiling GDAL, or with the grass-gdal plugin? I cannot get the grass-gdal plugin to compile after removing all grass6 files, and installing grass7. I have updated my ld.so.conf to reflect these changes, but still get:

./configure --with-grass=/usr/local/grass-7.0.svn/
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for ranlib... ranlib
checking for g++ -shared ... yes
checking for gdal-config... /usr/local/bin/gdal-config
using /usr/local/lib/gdalplugins as GDAL shared library autoload directory
checking for G_asprintf in -lgrass_gis... no
configure: error: --with-grass=/usr/local/grass-7.0.svn/ requested, but libraries not found!

comment:7 by Even Rouault, 12 years ago

Cc: martinl added

I think the grass-gdal plugin is the way to go, but there hasn't been any activity recently, so it might not work either as grass7 must be still a moving target I imagine. CC'ing Martin Landa who has declared the GRASS driver as area of interest ;-)

comment:8 by kalxas, 12 years ago

Hi all,

Any progress on this issue? Has anyone had success building against current grass7 trunk?

Regards, Angelos

comment:9 by Even Rouault, 12 years ago

Milestone: 1.7.0
Resolution: fixed
Status: closedreopened

Reopening the ticket. Any volunteer ?

comment:10 by pvanbosgeo, 12 years ago

Hi, any development in this regard? GRASS 7.0 seems fairly stable for most work, so it would be great if the grass-gdal plugin could be made compatible with grass 7.0. I can't program, but I would be happy to test.

comment:11 by Markus Neteler, 12 years ago

I just tried with GRASS 7.svn and this part went through properly:

[neteler@north gdal-1.9]$ ./configure --with-grass=/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/
...
checking for PostgreSQL... no
checking for G_asprintf in -lgrass_gis... yes
checking for ffopen in -lcfitsio... no
...
GDAL is now configured for x86_64-unknown-linux-gnu
...
  GRASS support:             grass57+
...

Essential (in fact small) updates are:

  • /usr/bin/ld: cannot find -lgrass_vect --> the GRASS7 name is 'grass_vector'
  • /usr/bin/ld: cannot find -lgrass_I --> the GRASS7 name is 'grass_imagery'
  • /usr/bin/ld: cannot find -lgrass_vask --> no longer exists in GRASS7

This would require to be conditionalized in the Makefile upon the GRASS version.

in reply to:  7 comment:12 by martinl, 12 years ago

Replying to rouault:

I think the grass-gdal plugin is the way to go, but there hasn't been any activity recently, so it might not work either as grass7 must be still a moving target I imagine. CC'ing Martin Landa who has declared the GRASS driver as area of interest ;-)

that's right, sorry I am super-busy with other important stuff. I will do my best to look at this issue too.

in reply to:  11 comment:13 by hamish, 12 years ago

Replying to neteler:

This would require to be conditionalized in the Makefile upon the GRASS version.

i.e. in include/grass/version.h test against GRASS_VERSION_MAJOR == 6 (or 7).

Hamish

comment:14 by kalxas, 11 years ago

FYI, I am getting requests for gdal support for grass7 in openSUSE.

https://bugzilla.novell.com/show_bug.cgi?id=723890

comment:15 by martinl, 11 years ago

Compilation issues fixed in r26318 + r26320. Martin

in reply to:  15 ; comment:16 by sbl, 10 years ago

Cc: sbl added

Replying to martinl:

Compilation issues fixed in r26318 + r26320. Martin

I just tried to compile GDAL (rev 26701) against GRASS 7 (rev 58438) on Ubunut Server 12.04 with unfortunately various results. It seems that the gdal-grass-plugin did not receive any updates since 2007 (latest version on http://download.osgeo.org/gdal/ is 1.4.3, last modified 05-Aug-2007). So I rebuild GDAL after compiling GRASS 7 (instead of using the plugin). After that, gdalinfo --formats gave:

Supported Formats:
  GRASS (ro):

No vesion information was given.

gdal_translate with GRASS raster datasets as input worked, but gave warning:

 Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
  /usr/local/grass-7.0.svn

However, raster2pgsql from PostGIS 2.1.2 gave error messages when I try to feed GRASS raster:

Segmentation fault (core dumped)" 

After I removed "/usr/local/grass-6.4.4svn/lib" from /etc/ld.so.conf error messages changed to:

ERROR 1: libgrass_I.so: cannot open shared object file: No such file or directory
*** glibc detected *** raster2pgsql: corrupted double-linked list: 
0x00000000012e59f0 ***

To me it looks like GDAL is using a mixture of GRASS 6 and GRASS 7, becaus it said it was using GRASS 7 GISBASE but was looking for libgrass_I.so (wich is GRASS 6 specific I think?). See also: http://lists.osgeo.org/pipermail/grass-dev/2013-December/066608.html for discussion on grass-dev mailinglist.

comment:17 by larrysh, 10 years ago

Hi,

I would be interested in helping on getting this functioning, now that the GRASS 7 beta1 is out.

The patches attached here are outdated, but it looks like there is GRASS support in 1.10 already, just not in the plugin, yet.

comment:18 by Even Rouault, 10 years ago

The potential changes are to be done in frmts/grass/grassdataset.cpp, GDAL's configure.in (root of source tree) and plugin configure.in in frmts/grass/pkg

in reply to:  18 comment:19 by martinl, 10 years ago

Replying to rouault:

The potential changes are to be done in frmts/grass/grassdataset.cpp, GDAL's configure.in (root of source tree) and plugin configure.in in frmts/grass/pkg

The configure script should detect GRASS 7 already correctly

 GRASS support:             grass70+

On the rest I will try take a look ASAP.

in reply to:  16 ; comment:20 by martinl, 10 years ago

Replying to sbl:

gdal_translate with GRASS raster datasets as input worked, but gave warning:

 Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
  /usr/local/grass-7.0.svn

that's absolutely OK, it's just a warning that GDAL will use the version of GRASS which was used when building GDAL. If you want to use different version of GRASS, you can define it by GISBASE variable. Anyway this warning is probably misleading. The driver should probably check if GRASS_GISBASE exists on local machine and if not found than fail with error message: "Default GISBASE (%s) not found, you need to define GISBASE environmental variable which points to your GRASS installation". What do you think?

in reply to:  20 comment:21 by sbl, 10 years ago

Description: modified (diff)

Replying to martinl:

Replying to sbl:

gdal_translate with GRASS raster datasets as input worked, but gave warning:

 Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
  /usr/local/grass-7.0.svn

that's absolutely OK, it's just a warning that GDAL will use the version of GRASS which was used when building GDAL. If you want to use different version of GRASS, you can define it by GISBASE variable. Anyway this warning is probably misleading. The driver should probably check if GRASS_GISBASE exists on local machine and if not found than fail with error message: "Default GISBASE (%s) not found, you need to define GISBASE environmental variable which points to your GRASS installation". What do you think?

comment:22 by sbl, 10 years ago

Description: modified (diff)

in reply to:  20 comment:23 by sbl, 10 years ago

Replying to martinl:

that's absolutely OK, it's just a warning that GDAL will use the version of GRASS which was used when building GDAL. If you want to use different version of GRASS, you can define it by GISBASE variable. Anyway this warning is probably misleading. The driver should probably check if GRASS_GISBASE exists on local machine and if not found than fail with error message: "Default GISBASE (%s) not found, you need to define GISBASE environmental variable which points to your GRASS installation". What do you think?

That sounds reasonable.

I just tested GDAL 1.11 RC1. It now compiles fine with GRASS 7 support and reads both GRASS 6 and 7 raster and vector (for vector I only tested GRASS 7 vectors).

Yet, I have two GRASS installations (GRASS 6.4.4 and GRASS 7) and had to remove /usr/local/grass-6.4.4svn/lib from /etc/ld.so.config in order to make GDAL work with GRASS data (before I got "ERROR: Incompatible library version for module. You need to rebuild GRASS or untangle multiple installations").

Anyway, many thanks for making that functioning!

(Sorry, wrote into the wrong text field at first..)

comment:24 by hcho, 10 years ago

I just tried to compile GDAL SVN (April 24, 2014) against GRASS 7 SVN (March 13, 2014) and needed two more libraries in configure (-lgrass_ccmath -lgrass_btree2). The patch is attached.

by hcho, 10 years ago

Attachment: patch-configure added

-lgrass_ccmath -lgrass_btree2

by hcho, 10 years ago

Attachment: patch-configure.in added

-lgrass_ccmath -lgrass_btree2

comment:25 by hcho, 10 years ago

Reading offset was incorrect. One more patch attached.

in reply to:  25 comment:26 by hcho, 10 years ago

Replying to hcho:

Reading offset was incorrect. One more patch attached.

Hmm... I was wrong. I had to use Rast_get/set_window instead of G_get/set_window.

by hcho, 10 years ago

Use Rast_get/set_window with GRASS 7.

comment:27 by pvanbosgeo, 10 years ago

I compiled gdal with grass7 support (compile gdal without grass, than grass, than gdal with grass support). It all compiled without error. And e.g., ogrinfo seemed to work:

Running:

$ export GISBASE=/usr/local/grass7/grass-7.1.svn
$ ogrinfo -ro /home/paulo/Data/GRASSdb/latlon/climate/vector/Ethiopia/head

gives:

INFO: Open of `/home/paulo/Data/GRASSdb/latlon/climate/vector/Ethiopia/head'
      using driver `GRASS' successful.
1: 0 (Line String)
2: ethiopia (Polygon)

Which seems to suggest it works?

However, I don't manage to compile QGIS with GRASS support, even though QGIS compiles fine without grass support. I also tried the patches mentioned above, with the same result. This makes me wonder if the compilation of gdal failed after all. See below the relevant lines of the console output:

[ 24%] Built target gpxprovider
Scanning dependencies of target crssync
[ 24%] Building CXX object src/providers/grass/CMakeFiles/qgisgrass.dir/qgsgrass.cpp.o
[ 24%] Generating qrc_images.cxx
[ 24%] Building CXX object src/crssync/CMakeFiles/crssync.dir/main.cpp.o
Linking CXX executable ../../output/bin/crssync
[ 24%] Generating moc_qgshelpviewer.cxx
[ 24%] Generating ui_qgshelpviewerbase.h
/home/paulo/Software/spatial/Quantum-GIS/src/providers/grass/qgsgrass.cpp: In static member function ‘static void QgsGrass::setLocation(QString, QString)’:
/home/paulo/Software/spatial/Quantum-GIS/src/providers/grass/qgsgrass.cpp:381:35: error: ‘G_available_mapsets’ was not declared in this scope
   char **ms = G_available_mapsets();
                                   ^
/home/paulo/Software/spatial/Quantum-GIS/src/providers/grass/qgsgrass.cpp: In static member function ‘static void QgsGrass::setMapset(QString, QString, QString)’:
/home/paulo/Software/spatial/Quantum-GIS/src/providers/grass/qgsgrass.cpp:400:35: error: ‘G_available_mapsets’ was not declared in this scope
   char **ms = G_available_mapsets();
                                   ^
Scanning dependencies of target qgis_help
[ 44%] Built target qgis_gui
[ 44%] Building CXX object src/providers/grass/CMakeFiles/qgisgrass.dir/qgsgrassfeatureiterator.cpp.o
make[2]: *** [src/providers/grass/CMakeFiles/qgisgrass.dir/qgsgrass.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 44%] Building CXX object src/helpviewer/CMakeFiles/qgis_help.dir/main.cpp.o
[ 44%] Building CXX object src/python/CMakeFiles/qgispython.dir/qgispython.cpp.o
[ 44%] Built target crssync
[ 44%] Generating analysis/sip_analysispart0.cpp, analysis/sip_analysispart1.cpp, analysis/sip_analysispart2.cpp, analysis/sip_analysispart3.cpp

[ 44%] Building CXX object src/python/CMakeFiles/qgispython.dir/qgspythonutilsimpl.cpp.o
/home/paulo/Software/spatial/Quantum-GIS/src/providers/grass/qgsgrassfeatureiterator.cpp: In constructor ‘QgsGrassFeatureSource::QgsGrassFeatureSource(const QgsGrassProvider*)’:
/home/paulo/Software/spatial/Quantum-GIS/src/providers/grass/qgsgrassfeatureiterator.cpp:619:7: warning: unused variable ‘layerId’ [-Wunused-variable]
   int layerId = QgsGrassProvider::openLayer( p->mGisdbase, p->mLocation, p->mMapset, p->mMapName, p->mLayerField );
       ^
make[1]: *** [src/providers/grass/CMakeFiles/qgisgrass.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 44%] [ 44%] Building CXX object src/helpviewer/CMakeFiles/qgis_help.dir/qgshelpviewer.cpp.o
Building CXX object src/helpviewer/CMakeFiles/qgis_help.dir/moc_qgshelpviewer.cxx.o
Linking CXX shared library ../../output/lib/libqgispython.so
[ 44%] [ 44%] Built target qgispython
Building CXX object src/helpviewer/CMakeFiles/qgis_help.dir/qrc_images.cxx.o
Linking CXX executable ../../output/lib/qgis/qgis_help
[ 44%] Built target qgis_help
Scanning dependencies of target python_module_qgis__analysis
[ 44%] [ 44%] [ 44%] [ 44%] Building CXX object python/CMakeFiles/python_module_qgis__analysis.dir/analysis/sip_analysispart0.cpp.o
Building CXX object python/CMakeFiles/python_module_qgis__analysis.dir/analysis/sip_analysispart2.cpp.o
Building CXX object python/CMakeFiles/python_module_qgis__analysis.dir/analysis/sip_analysispart1.cpp.o
Building CXX object python/CMakeFiles/python_module_qgis__analysis.dir/analysis/sip_analysispart3.cpp.o
Linking CXX shared library ../output/python/qgis/_analysis.so
[ 44%] Built target python_module_qgis__analysis
make: *** [all] Error 2

Any idea what may be wrong (I am posting here because I guess it has something to do with the gdal-grass integration. But let me know if I should post this on the QGIS mailing list).

comment:28 by Even Rouault, 10 years ago

The GRASS integration in QGIS has nothing to do with the gdal-grass plugin, so yes please report that to the QGIS channels.

comment:29 by Markus Neteler, 10 years ago

FWIW: there was a recent API change in GRASS GIS 7 (not yet officially released):

http://trac.osgeo.org/grass/changeset/60603

http://trac.osgeo.org/grass/changeset/60508

where the function was renamed.

in reply to:  28 comment:30 by pvanbosgeo, 10 years ago

Replying to rouault:

The GRASS integration in QGIS has nothing to do with the gdal-grass plugin, so yes please report that to the QGIS channels.

Thanks for the feedback. I would say it does in that the integration in qgis completely depends on grass support in gdal. If that works (through the gdal-grass plugin or by compiling gdal with grass support directly), there should be no problem compiling QGIS with grass. But in any case I just reported it on the QGIS channels. I am still wondering though if the compiling of gdal with grass support actually succeeded... need to find a way to better test this).

comment:31 by Even Rouault, 10 years ago

Well, in QGIS, there's potential use of the gdal-grass plugin of course, but this is a runtime use, not a compile time. But in QGIS there's also QGIS code that calls GRASS directly, likely for the Processing function of QGIS. The compilation errors you mentionned are in QGIS sources, not GDAL ones.

in reply to:  2 comment:32 by Markus Neteler, 10 years ago

Milestone: 1.11.1

Replying to rouault:

Grass enhancement request : it would be cool if GRASS had a grass-config script.

There is now:

grass70 --config

#  --config     print GRASS configuration parameters
#                options: arch,build,compiler,path,revision

grass70 --config build
./configure  --with-cxx --enable-largefile --with-proj --with-gdal=/usr/bin/gdal-config --with-python --with-geos --with-cairo --with-cairo-ldflags=-lfontconfig --with-sqlite --with-nls --with-liblas --with-openmp --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-wxwidget --with-fftw --with-motif --with-postgres --with-netcdf --without-mysql --without-odbc --without-ffmpeg

comment:33 by Jukka Rahkonen, 9 years ago

If I understood right, someone has managed to compile GDAL with GRASS 7.

Is this ticket ready for closing as fixed?

in reply to:  33 comment:34 by Markus Neteler, 9 years ago

Replying to jratike80:

If I understood right, someone has managed to compile GDAL with GRASS 7.

Is this ticket ready for closing as fixed?

I don't think so as it was not updated in GDAL (I checked right now 1.11.svn):

configure:2939: checking for G_asprintf in -lgrass_gis
configure:2969: gcc -o conftest -O2    conftest.c -lgrass_gis -L/home/neteler/software/grass70/dist.x86_64-unknown-linux-gnu/lib -lgrass_I -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj -lgrass_vect -lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2 -lgrass_rtree -lgrass_linkm -L/usr/lib64 -lgdal  >&5
/usr/bin/ld: cannot find -lgrass_I
/usr/bin/ld: cannot find -lgrass_vask
/usr/bin/ld: cannot find -lgrass_vect
...

This indicates that it still tries to find the old GRASS 6 libs and does not autodetect GRASS 7.

comment:35 by martinl, 9 years ago

Milestone: 1.11.11.11.2

comment:36 by Markus Neteler, 9 years ago

For the record: Some fix applied in r28291

comment:37 by Even Rouault, 9 years ago

Resolution: fixed
Status: reopenedclosed

Closing as it seems the backport to 1.11 has been done

comment:38 by Markus Neteler, 9 years ago

Can you please publish it as a separate tarball "gdal-grass7-1.0.0.tar.gz" similar to

http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz

tar tvfz gdal-grass-1.4.3.tar.gz 
drwxr-xr-x warmerda/warmerda 0 2007-08-05 23:54 ./gdal-grass-1.4.3/
-rwxr-xr-x warmerda/warmerda 114354 2007-08-05 23:54 ./gdal-grass-1.4.3/configure
-rw-r--r-- warmerda/warmerda   1686 2007-08-05 23:54 ./gdal-grass-1.4.3/Makefile.in
-rw-r--r-- warmerda/warmerda   5226 2007-08-05 23:54 ./gdal-grass-1.4.3/configure.in
-rw-r--r-- warmerda/warmerda   5914 2007-08-05 23:54 ./gdal-grass-1.4.3/aclocal.m4
-rw-r--r-- warmerda/warmerda   2086 2007-08-05 23:54 ./gdal-grass-1.4.3/README
-rw-r--r-- warmerda/warmerda  33147 2007-08-05 23:54 ./gdal-grass-1.4.3/grass57dataset.cpp
-rw-r--r-- warmerda/warmerda  11419 2007-08-05 23:54 ./gdal-grass-1.4.3/ogrgrassdatasource.cpp
-rw-r--r-- warmerda/warmerda   4450 2007-08-05 23:54 ./gdal-grass-1.4.3/ogrgrassdriver.cpp
-rw-r--r-- warmerda/warmerda  30366 2007-08-05 23:54 ./gdal-grass-1.4.3/ogrgrasslayer.cpp
-rw-r--r-- warmerda/warmerda   6647 2007-08-05 23:54 ./gdal-grass-1.4.3/ogrgrass.h

? This would greatly help to get it as a package into the various distros. Thanks.

comment:39 by Even Rouault, 9 years ago

Markus, I guess you missed the 1.11.2RC1/RC2 news ;-) ? See http://lists.osgeo.org/pipermail/gdal-dev/2015-February/041007.html

in reply to:  39 comment:40 by Markus Neteler, 9 years ago

Replying to rouault:

Markus, I guess you missed the 1.11.2RC1/RC2 news ;-) ? See http://lists.osgeo.org/pipermail/gdal-dev/2015-February/041007.html

Wonderful, thanks so much!

comment:41 by pvanbosgeo, 9 years ago

I am trying to compile the plugin for grass 7.1, but it fails, not being able to find the grass libraries:

configure: error: --with-grass=/usr/local/grass7/grass-7.1.svn requested, but libraries not found!  Perhaps you need to set LD_LIBRARY_PATH to include /usr/local/grass7/grass-7.1.svn/lib?

Checking the configure file, on line 3088 library references are specifically for grass 7.0

LIBS="-L$with_grass/lib -lgrass_raster.7.0.svn -lgrass_gmath.7.0.svn -lgrass_gis.7.0.svn -lgrass_datetime.7.0.svn -lgrass_gproj.7.0.svn -lgrass_vector.7.0.svn -lgrass_dbmibase.7.0.svn -lgrass_dbmiclient.7.0.svn -lgrass_dgl.7.0.svn -lgrass_dig2.7.0.svn -lgrass_rtree.7.0.svn -lgrass_linkm.7.0.svn -lgrass_btree2.7.0.svn -lgrass_ccmath.7.0.svn $LIBS"

Replacing 7.0 by 7.1 in the configure file did not work though. Also, as at least in my GRASS install (compiled from master) links to these libraries are created without the version number (e.g., libgrass_gmath.so to libgrass_gmath.7.0.svn.so) I tried to use these, but doesn't work either.

Any idea how to solve this / what I am doing wrong?

Perhaps this can be changed to something like

in reply to:  41 comment:42 by martinl, 9 years ago

Replying to pvanbosgeo:

I am trying to compile the plugin for grass 7.1, but it fails, not being able to find the grass libraries:

configure: error: --with-grass=/usr/local/grass7/grass-7.1.svn requested, but libraries not found!  Perhaps you need to set LD_LIBRARY_PATH to include /usr/local/grass7/grass-7.1.svn/lib?

I am unable to reproduce this error, what is content of /usr/local/grass7/grass-7.1.svn and /usr/local/grass7/grass-7.1.svn/lib?

comment:43 by pvanbosgeo, 9 years ago

in /usr/local/grass7/grass-7.1.svn/lib: libgrass_arraystats.7.1.svn.so, libgrass_arraystats.so, libgrass_bitmap.7.1.svn.so, libgrass_bitmap.so, etc.

in /usr/local/grass7/grass-7.1.svn the folders: bin, demolocation, docs, drivers, etc, fonts, gui, include, lib, scripts, share, tools and the files AUTHORS, CHANGES, config.status, contributors.csv, contributors_extra.csv, COPYING, GPL.TXT, REQUIREMENTS.html, translators.csv

I also did set the LD_LIBRARY_PATH using:

sudo sh -c "echo /usr/local/grass7/grass-7.1.svn/lib > /etc/ld.so.conf.d/grass.conf"
cd /etc/ld.so.conf.d/
sudo ldconfig

comment:44 by pvanbosgeo, 9 years ago

OK, followed the advise in the README file to set path to geo-config and proj in /etc/ld.so.conf. Now running configure ends in the following:

user supplied gdal-config (/usr/local/gdal/bin/gdal-config) using /usr/local/gdal/lib/gdalplugins as GDAL shared library autoload directory checking for G_asprintf in -lgrass_gis... no checking for G_putenv in -lgrass_gis.7.1.svn... ./configure: line 3019: ${ac_cv_lib_grass_gis_7.1_svn_G_putenv+set}: bad substitution configure: creating ./config.status config.status: creating Makefile

If I run make now, I get:

g++ -Wall -fPIC -DUSE_CPL -DGRASS_GISBASE=\"\" -I/usr/local/gdal/include -c -o grass57dataset.o grass57dataset.cpp grass57dataset.cpp:40:27: fatal error: grass/imagery.h: No such file or directory

#include <grass/imagery.h>

compilation terminated. make: * [grass57dataset.o] Error 1

comment:45 by Bas Couwenberg, 9 years ago

Hacking the configure script is not recommended. The current grass7+ detection in configure.in only supports GRASS 7.0 SVN, to support GRASS 7.0.0RC2 you need to test for grass_gis.7.0.0RC2. To support GRASS 7.0.0RC2 I used the following:

--- a/configure.in
+++ b/configure.in
@@ -131,14 +131,22 @@ if test "$with_grass" != "yes" ; then
     GRASS_GISBASE="$with_grass"
   else

-    # Check for GRASS >= 7.0
+    # Check for GRASS >= 7.0 (SVN)
     AC_CHECK_LIB(grass_gis.7.0.svn,G_putenv,GRASS_SETTING=grass7+,GRASS_SETTING=no,-L$with_grass/lib -lgrass_raster.7.0.svn -lgrass_gmath.7.0.svn -lgrass_gis.7.0.svn -lgrass_datetime.7.0.svn -lgrass_gproj.7.0.svn -lgrass_vector.7.0.svn -lgrass_dbmibase.7.0.svn -lgrass_dbmiclient.7.0.svn -lgrass_dgl.7.0.svn -lgrass_dig2.7.0.svn -lgrass_rtree.7.0.svn -lgrass_linkm.7.0.svn -lgrass_btree2.7.0.svn -lgrass_ccmath.7.0.svn)
     if test "$GRASS_SETTING" = "grass7+" ; then
         LIBS="-L$with_grass/lib -lgrass_raster.7.0.svn -lgrass_gmath.7.0.svn -lgrass_gis.7.0.svn -lgrass_datetime.7.0.svn -lgrass_gproj.7.0.svn -lgrass_vector.7.0.svn -lgrass_dbmibase.7.0.svn -lgrass_dbmiclient.7.0.svn -lgrass_dgl.7.0.svn -lgrass_dig2.7.0.svn -lgrass_rtree.7.0.svn -lgrass_linkm.7.0.svn -lgrass_btree2.7.0.svn -lgrass_ccmath.7.0.svn $LIBS"
         GRASS_INCLUDE="-I$with_grass/include"
         GRASS_GISBASE="$with_grass"
     else
-        AC_MSG_ERROR([--with-grass=$with_grass requested, but libraries not found!  Perhaps you need to set LD_LIBRARY_PATH to include $with_grass/lib?])
+        # Check for GRASS 7.0.0RC2
+        AC_CHECK_LIB(grass_gis.7.0.0RC2,G_putenv,GRASS_SETTING=grass7+,GRASS_SETTING=no,-L$with_grass/lib -lgrass_raster.7.0.0RC2 -lgrass_gmath.7.0.0RC2 -lgrass_gis.7.0.0RC2 -lgrass_datetime.7.0.0RC2 -lgrass_gproj.7.0.0RC2 -lgrass_vector.7.0.0RC2 -lgrass_dbmibase.7.0.0RC2 -lgrass_dbmiclient.7.0.0RC2 -lgrass_dgl.7.0.0RC2 -lgrass_dig2.7.0.0RC2 -lgrass_rtree.7.0.0RC2 -lgrass_linkm.7.0.0RC2 -lgrass_btree2.7.0.0RC2 -lgrass_ccmath.7.0.0RC2)
+        if test "$GRASS_SETTING" = "grass7+" ; then
+            LIBS="-L$with_grass/lib -lgrass_raster.7.0.0RC2 -lgrass_gmath.7.0.0RC2 -lgrass_gis.7.0.0RC2 -lgrass_datetime.7.0.0RC2 -lgrass_gproj.7.0.0RC2 -lgrass_vector.7.0.0RC2 -lgrass_dbmibase.7.0.0RC2 -lgrass_dbmiclient.7.0.0RC2 -lgrass_dgl.7.0.0RC2 -lgrass_dig2.7.0.0RC2 -lgrass_rtree.7.0.0RC2 -lgrass_linkm.7.0.0RC2 -lgrass_btree2.7.0.0RC2 -lgrass_ccmath.7.0.0RC2 $LIBS"
+            GRASS_INCLUDE="-I$with_grass/include"
+            GRASS_GISBASE="$with_grass"
+        else
+            AC_MSG_ERROR([--with-grass=$with_grass requested, but libraries not found!  Perhaps you need to set LD_LIBRARY_PATH to include $with_grass/lib?])
+        fi
     fi
   fi
 fi

To support GRASS 7.1 SVN you'd need a to add yet another AC_CHECK_LIB.

You'll also need to update the paths for the .table files that moved from etc/ to etc/proj/:

--- a/Makefile.in
+++ b/Makefile.in
@@ -30,8 +30,8 @@ install:      default
        cp $(OLIBNAME) $(AUTOLOAD_DIR)
        test -d ${GRASSTABLES_DIR} || mkdir ${GRASSTABLES_DIR}
        test -d ${GRASSTABLES_DIR}/etc || mkdir ${GRASSTABLES_DIR}/etc
-       cp @GRASS_GISBASE@/etc/ellipse.table ${GRASSTABLES_DIR}/etc
-       cp @GRASS_GISBASE@/etc/datum.table @GRASS_GISBASE@/etc/datumtransform.table ${GRASSTABLES_DIR}/etc
+       cp @GRASS_GISBASE@/etc/proj/ellipse.table ${GRASSTABLES_DIR}/etc
+       cp @GRASS_GISBASE@/etc/proj/datum.table @GRASS_GISBASE@/etc/proj/datumtransform.table ${GRASSTABLES_DIR}/etc
        test -d ${GRASSTABLES_DIR}/driver || mkdir ${GRASSTABLES_DIR}/driver
        test -d ${GRASSTABLES_DIR}/driver/db || mkdir ${GRASSTABLES_DIR}/driver/db
        cp -r @GRASS_GISBASE@/driver/db/* ${GRASSTABLES_DIR}/driver/db/

comment:46 by pvanbosgeo, 9 years ago

I tried to follow the suggestions by sebastic, but still no luck. Anybody managed to compile this wil grass 7.1 / master?

in reply to:  46 ; comment:47 by Bas Couwenberg, 9 years ago

Replying to pvanbosgeo:

I tried to follow the suggestions by sebastic, but still no luck. Anybody managed to compile this wil grass 7.1 / master?

Try the GRASS 7.0.0 patches from #5852, those have much better 7.0.0 support than the ones from #comment:45

in reply to:  47 comment:48 by martinl, 9 years ago

Replying to sebastic:

Try the GRASS 7.0.0 patches from #5852, those have much better 7.0.0 support than the ones from #comment:45

BTW, few minutes ago applied in GDAL trunk.

comment:49 by Markus Neteler, 7 years ago

Milestone: 1.11.22.1.3
Resolution: fixed
Status: closedreopened

I take liberty to re-open this due to an issue found:

While creating a gdal-grass Fedora RPM package (based on GDAL 2.1 branch):

https://copr.fedorainfracloud.org/coprs/neteler/gdal-grass-plugin/

I discovered an issue in Makefile.in which should be fixed:

All the etc/ .. table/datum/ stuff should not be installed but called from GRASS GIS 7 itself.

Basically:

  • remove those "test .. | | mkdir .." lines from Makefile.in
  • remove the related "cp .. ${GRASSTABLES_DIR}.." lines from Makefile.in
  • when compiling, use something like --with-grass=/usr/lib64/grass72/ and all will be found.

It would be ideal to then release a gdal-grass-2.1.x.tar.gz package.

comment:50 by Even Rouault, 7 years ago

Markus, can you prepare a patch for this ? Does this apply to particular GRASS versions ? By the way, Bas Couwenberg submitted a patch for GRASS 7.2 support which I've applied: https://trac.osgeo.org/gdal/ticket/6785

by Markus Neteler, 7 years ago

Attachment: Makefile.in.diff added

Patch to not clone datum tables and drivers

in reply to:  50 ; comment:51 by Markus Neteler, 7 years ago

Replying to rouault:

Markus, can you prepare a patch for this ? Does this apply to particular GRASS versions ?

Sure, done. I think is is valid for all GRASS versions since the structure didn't change here.

By the way, Bas Couwenberg submitted a patch for GRASS 7.2 support which I've applied: https://trac.osgeo.org/gdal/ticket/6785

Great, thanks. Maybe Bas can test my patch and then a new plugin src tarball could be released.

comment:52 by Even Rouault, 7 years ago

Resolution: fixed
Status: reopenedclosed

In 37164:

frmts/grass/pkg/Makefile.in: do not clone datum tables and drivers (patch by Markus Neteler, fixes #2953)

comment:53 by Even Rouault, 7 years ago

In 37165:

frmts/grass/pkg/Makefile.in: do not clone datum tables and drivers (patch by Markus Neteler, fixes #2953)

comment:54 by Even Rouault, 7 years ago

Makefile.in.diff applied

A new GDAL-GRASS tarball will be released together GDAL 2.1.3 end of this week.

in reply to:  51 comment:55 by Bas Couwenberg, 7 years ago

Replying to neteler:

Great, thanks. Maybe Bas can test my patch and then a new plugin src tarball could be released.

The conditions triggering the copy commands don't occur for the Debian package build, which only installs the two libraries.

comment:56 by Nikos Alexandris, 6 years ago

Dears,

In a system with 'GDAL 2.2.3, released 2017/11/20' installed, I downloaded gdal-grass-2.2.3.tar.gz. I tried to build the driver after having set soft-links under /usr/local/lib pointing to /osgeo/grasstrunk/dist.x86_64-pc-linux-gnu/lib/*.so files and related paths to gdal, geos, proj and grasstrunk /etc/ld.so.conf.d/grasstrunk.conf followed by ldconfig.

After the configure phase, make fails as follows:

g++ -Wall -fPIC -DUSE_CPL -DGRASS_GISBASE=\"/osgeo/grasstrunk/dist.x86_64-pc-linux-gnu/lib\" -I/usr/include/gdal -I/osgeo/grasstrunk/dist.x86_64-pc-linux-gnu/lib/include   -O2  -c -o grass57dataset.o grass57dataset.cpp
grass57dataset.cpp:44:27: fatal error: grass/imagery.h: No such file or directory
compilation terminated.
Makefile:43: recipe for target 'grass57dataset.o' failed
make: *** [grass57dataset.o] Error 1

Searching in the file 'configure.in', as referenced in comment:45, I see that grass72+ are the latest supported versions.

While wrongly trying to build against 'grasstrunk' (or would/should that be possible too?), and should instead build the driver against a 7.2 version, still: doesn't this deserve an update, to at least version 7.4?

Nikos

comment:57 by Even Rouault, 6 years ago

Not sure if that works, but you should try with GDAL master. GDAL 2.2 won't likely receive any new bugfix version at that point now that 2.3.0 has been released.

Note: See TracTickets for help on using tickets.