Opened 4 years ago

Closed 4 years ago

#5852 closed defect (fixed)

GRASS 7.0.0 support

Reported by: Bas Couwenberg Owned by: warmerdam
Priority: normal Milestone: 1.11.3
Component: default Version: svn-trunk
Severity: normal Keywords:
Cc: martinl, Markus Neteler, imincik1

Description (last modified by Bas Couwenberg)

GRASS 7 moved the .table files from @GRASS_GISBASE@/etc to @GRASS_GISBASE@/etc/proj, causing the install target of the plugin to fail.

The configure script for the GRASS plugin only support GRASS 7.0 from SVN, but not the final release.

The attached patch fixes both issue. The .table files are copied conditionally, and a second check for the final GRASS 7.0.0 library is added in case 7.0 SVN was not found.

Attachments (4)

grass-7.0.0.patch (3.9 KB) - added by Bas Couwenberg 4 years ago.
gdal-grass-configure.patch (3.0 KB) - added by martinl 4 years ago.
gdal-grass-makefile.patch (1.4 KB) - added by Bas Couwenberg 4 years ago.
grass-configure-postgres.patch (3.5 KB) - added by martinl 4 years ago.

Download all attachments as: .zip

Change History (29)

Changed 4 years ago by Bas Couwenberg

Attachment: grass-7.0.0.patch added

comment:1 Changed 4 years ago by Even Rouault

Cc: martinl added

comment:2 Changed 4 years ago by martinl

@sebastic: could you please try attachment:gdal-grass-configure.patch instead of your version?

Changed 4 years ago by martinl

Attachment: gdal-grass-configure.patch added

Changed 4 years ago by Bas Couwenberg

Attachment: gdal-grass-makefile.patch added

comment:3 in reply to:  2 Changed 4 years ago by Bas Couwenberg

Description: modified (diff)

Replying to martinl:

@sebastic: could you please try attachment:gdal-grass-configure.patch instead of your version?

Thanks for your patch, it looks like a much better way to support future GRASS 7 versions.

I've included your patch in the Debian package for the GDAL GRASS plugin and the resulting build with GRASS 7.0.0 looks good.

comment:4 Changed 4 years ago by Bas Couwenberg

Description: modified (diff)

comment:5 Changed 4 years ago by Bas Couwenberg

I've attached an updated version of my patch (attachment:gdal-grass-makefile.patch) to only change the Makefile.in adding support for both paths of the .table files.

Together with attachment:gdal-grass-configure.patch it should solve this issue nicely.

comment:6 in reply to:  5 Changed 4 years ago by martinl

Replying to sebastic:

I've attached an updated version of my patch (attachment:gdal-grass-makefile.patch) to only change the Makefile.in adding support for both paths of the .table files.

Together with attachment:gdal-grass-configure.patch it should solve this issue nicely.

I have applied your patches in r28591 together with updated configure.

comment:7 Changed 4 years ago by martinl

But when following README

./configure ...
make
sudo make install

make fails in pkg directory with

~/src/gdal/frmts/grass/pkg$ make
make: *** No rule to make target 'grass57dataset.o', needed by 'gdal_GRASS.so'.  Stop.

comment:8 in reply to:  7 ; Changed 4 years ago by Bas Couwenberg

Replying to martinl:

make fails in pkg directory with

~/src/gdal/frmts/grass/pkg$ make
make: *** No rule to make target 'grass57dataset.o', needed by 'gdal_GRASS.so'.  Stop.

Perhaps an autoconf version mismatch?

The configure generated from configure.in during the Debian package builds works as expected. The package uses autoreconf -f -i to retool the build system.

dh_auto_configure -- --prefix=/usr --with-grass=/usr/lib/grass70 --with-autoload=/usr/lib/gdalplugins/1.11
configure: WARNING: unrecognized options: --disable-maintainer-mode, --disable-dependency-tracking
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
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 ISO C89... 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/bin/gdal-config
using /usr/lib/gdalplugins/1.11 as GDAL shared library autoload directory
checking for G_is_initialized in -lgrass_gis... yes
configure: creating ./config.status
config.status: creating Makefile
configure: WARNING: unrecognized options: --disable-maintainer-mode, --disable-dependency-tracking
make[1]: Leaving directory '/tmp/buildd/libgdal-grass-1.11.2'
   dh_auto_build -O--parallel
make[1]: Entering directory '/tmp/buildd/libgdal-grass-1.11.2'
g++ -Wall -fPIC  -DUSE_CPL -DGRASS_GISBASE=\"/usr/lib/grass70\" -I/usr/include/gdal -I/usr/lib/grass70/include -I/usr/include/postgresql -D_FORTIFY_SOURCE=2 -O2 -fstack-protector-strong -Wformat -Werror=format-security  -c -o grass57dataset.o grass57dataset.cpp
g++ -Wall -fPIC  -DUSE_CPL -DGRASS_GISBASE=\"/usr/lib/grass70\" -I/usr/include/gdal -I/usr/lib/grass70/include -I/usr/include/postgresql -D_FORTIFY_SOURCE=2 -O2 -fstack-protector-strong -Wformat -Werror=format-security  -c -o ogrgrassdriver.o ogrgrassdriver.cpp
g++ -Wall -fPIC  -DUSE_CPL -DGRASS_GISBASE=\"/usr/lib/grass70\" -I/usr/include/gdal -I/usr/lib/grass70/include -I/usr/include/postgresql -D_FORTIFY_SOURCE=2 -O2 -fstack-protector-strong -Wformat -Werror=format-security  -c -o ogrgrassdatasource.o ogrgrassdatasource.cpp
g++ -Wall -fPIC  -DUSE_CPL -DGRASS_GISBASE=\"/usr/lib/grass70\" -I/usr/include/gdal -I/usr/lib/grass70/include -I/usr/include/postgresql -D_FORTIFY_SOURCE=2 -O2 -fstack-protector-strong -Wformat -Werror=format-security  -c -o ogrgrasslayer.o ogrgrasslayer.cpp
g++ -shared  -Wl,-z,relro grass57dataset.o -L/usr/lib/grass70/lib -lgrass_vector -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_raster -lgrass_imagery -lgrass_gproj -lgrass_gmath -lgrass_gis -lgrass_datetime -L/usr/lib -lgdal  -o gdal_GRASS.so -Wl,-rpath,/usr/lib/grass70/lib
g++ -shared  -Wl,-z,relro ogrgrassdriver.o ogrgrassdatasource.o ogrgrasslayer.o -L/usr/lib/grass70/lib -lgrass_vector -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_raster -lgrass_imagery -lgrass_gproj -lgrass_gmath -lgrass_gis -lgrass_datetime -L/usr/lib -lgdal  -o ogr_GRASS.so -Wl,-rpath,/usr/lib/grass70/lib
make[1]: Leaving directory '/tmp/buildd/libgdal-grass-1.11.2'

comment:9 in reply to:  8 ; Changed 4 years ago by martinl

Replying to sebastic:

Perhaps an autoconf version mismatch?

I used autoconf2.69. Probably I misunderstood but running from GDAL source manually should also work, right?

cd frmts/grass/pkg
./configure --with-grass=...
make
make: *** No rule to make target 'grass57dataset.o', needed by 'gdal_GRASS.so'.  Stop.

?

comment:10 in reply to:  9 ; Changed 4 years ago by Bas Couwenberg

Replying to martinl:

Replying to sebastic:

Perhaps an autoconf version mismatch?

I used autoconf2.69.

I'm using autoconf 2.69 too.

Probably I misunderstood but running from GDAL source manually should also work, right?

It should, the libgdal-grass source is generated from the GDAL sources by the gdal Debian package. It runs configure in the top level directory and make dist on the plugin directory to create the tarball:

gdal-grass: override_dh_auto_configure gdal-grass-dist override_dh_auto_clean override_dh_clean
gdal-grass-dist:
        ln -fs $(CURDIR)/GDALmake.opt-$(PYDEF) $(CURDIR)/GDALmake.opt
        [ -e $(CURDIR)/GDALmake.opt ] && $(MAKE) -C $(CURDIR)/frmts/grass dist
        mv $(CURDIR)/frmts/grass/libgdal-grass-*.tar.gz $(CURDIR)/..
        rm -f $(CURDIR)/GDALmake.opt

You may be missing some make dist magic.

It looks like gdal/configure.in detects GRASS 7 differently from gdal/frmts/grass/pkg/configure.in.

comment:11 in reply to:  10 ; Changed 4 years ago by martinl

Replying to sebastic:

You may be missing some make dist magic.

right, this works

make -C frmts/grass/ dist
cd frmts/grass
tar xvzf gdal-grass-2.0.0.tar.gz
cd gdal-grass-2.0.0
./configure --with-grass=...
make
sudo make install

BTW, I wonder why it fails on my Debian unstable with

g++ -Wall -fPIC  -DUSE_CPL -DGRASS_GISBASE=\"/home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu\" -I/usr/local/include -I/home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include   -c -o ogrgrasslayer.o ogrgrasslayer.cpp
In file included from /home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vect/digit.h:3:0,
                 from /home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vector.h:4,
                 from ogrgrass.h:41,
                 from ogrgrasslayer.cpp:32:
/home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:31:22: fatal error: libpq-fe.h: No such file or directory
 #include <libpq-fe.h>

Do you have GRASS configured with PostgreSQL support?

comment:12 in reply to:  11 Changed 4 years ago by martinl

Replying to martinl:

> g++ -Wall -fPIC  -DUSE_CPL -DGRASS_GISBASE=\"/home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu\" -I/usr/local/include -I/home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include   -c -o ogrgrasslayer.o ogrgrasslayer.cpp
> In file included from /home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vect/digit.h:3:0,
>                  from /home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vector.h:4,
>                  from ogrgrass.h:41,
>                  from ogrgrasslayer.cpp:32:
> /home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:31:22: fatal error: libpq-fe.h: No such file or directory
>  #include <libpq-fe.h>

It seems to me that we need to add --with-postgres-includes option to frmt/grass/pkg/configure.in, right? I just wonder why it doesn't fail only my Debian machine.

comment:13 in reply to:  11 ; Changed 4 years ago by Bas Couwenberg

Replying to martinl:

BTW, I wonder why it fails on my Debian unstable with

/home/martin/src/grass70_release/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:31:22: fatal error: libpq-fe.h: No such file or directory
 #include <libpq-fe.h>

Do you have GRASS configured with PostgreSQL support?

The Debian package is configured with PostgresSQL support too, and needed to patch this issue too, see:

http://anonscm.debian.org/cgit/pkg-grass/gdal-grass.git/tree/debian/patches/libpq?h=experimental

Replying to martinl:

It seems to me that we need to add --with-postgres-includes option to frmt/grass/pkg/configure.in, right? I just wonder why it doesn't fail only my Debian machine.

That looks like a good solution, after patching the libpq issue I haven't looked further for a more proper fix.

comment:14 in reply to:  13 ; Changed 4 years ago by martinl

Replying to sebastic:

The Debian package is configured with PostgresSQL support too, and needed to patch this issue too, see:

http://anonscm.debian.org/cgit/pkg-grass/gdal-grass.git/tree/debian/patches/libpq?h=experimental

That looks like a good solution, after patching the libpq issue I haven't looked further for a more proper fix.

Please could you try this patch: attachment:grass-configure-postgres.patch

Changed 4 years ago by martinl

comment:15 in reply to:  14 ; Changed 4 years ago by Bas Couwenberg

Replying to martinl:

http://anonscm.debian.org/cgit/pkg-grass/gdal-grass.git/tree/debian/patches/libpq?h=experimental

Please could you try this patch: attachment:grass-configure-postgres.patch

Thanks for the patch, I've replaced the libpq patch in the Debian package in favor of yours. And like your previous patch, the resulting build with GRASS 7.0.0 looks good.

The build for GRASS 7 and the GDAL GRASS plugin is now more in line.

comment:16 in reply to:  15 ; Changed 4 years ago by martinl

Replying to sebastic:

Thanks for the patch, I've replaced the libpq patch in the Debian package in favor of yours. And like your previous patch, the resulting build with GRASS 7.0.0 looks good.

The build for GRASS 7 and the GDAL GRASS plugin is now more in line.

Applied in r28598. Any objection to backport r28591 and r28598 to 1_11 branch?

comment:17 in reply to:  16 ; Changed 4 years ago by Bas Couwenberg

Replying to martinl:

Applied in r28598. Any objection to backport r28591 and r28598 to 1_11 branch?

Not by me, I'm using those patches with 1.11.2 and would like to drop them when they're included in 1.11.3.

comment:18 in reply to:  17 Changed 4 years ago by martinl

Replying to sebastic:

Replying to martinl:

Applied in r28598. Any objection to backport r28591 and r28598 to 1_11 branch?

Not by me, I'm using those patches with 1.11.2 and would like to drop them when they're included in 1.11.3.

Done in r28712.

comment:19 in reply to:  14 ; Changed 4 years ago by martinl

Replying to martinl:

Please could you try this patch: attachment:grass-configure-postgres.patch

I am thinking whether it would be better to try to search for PG header somehow automatically and to drop added new switch --with-postgres-includes. What do you think. Main configure.in is behaving like that.

comment:20 in reply to:  19 ; Changed 4 years ago by Bas Couwenberg

Replying to martinl:

I am thinking whether it would be better to try to search for PG header somehow automatically and to drop added new switch --with-postgres-includes. What do you think. Main configure.in is behaving like that.

The configure behavior with the patch is identical to the configure process for GRASS itself, this makes sense.

Automatic configuration would be better, but would need to done in GRASS first/too.

comment:21 Changed 4 years ago by Markus Neteler

Cc: Markus Neteler added

comment:22 Changed 4 years ago by imincik1

Cc: imincik1 added

comment:23 in reply to:  20 ; Changed 4 years ago by martinl

Replying to sebastic:

The configure behavior with the patch is identical to the configure process for GRASS itself, this makes sense.

Automatic configuration would be better, but would need to done in GRASS first/too.

right. We can probably leave it as it is. Any objection to close this ticket?

comment:24 in reply to:  23 Changed 4 years ago by Bas Couwenberg

Replying to martinl:

right. We can probably leave it as it is. Any objection to close this ticket?

No objection, while automatic detection of the PostgreSQL headers would be nice it's not a must.

The current state of GRASS 7 support in the GDAL plugin with the patches from this issue is good enough for me.

comment:25 Changed 4 years ago by martinl

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.