Re: [gdal-dev] Compilation failure when excluding OGR Formats

2015-12-10 Thread Even Rouault
Le jeudi 10 décembre 2015 20:22:36, Timothy Astle a écrit : > I just tried to build the head of the GDAL trunk with the following > commented out in the opt file: > > #INCLUDE_OGR_FRMTS = YES > > The build fails because during the compilation of ogrutils. The > compiler has no idea what GDALGene

[gdal-dev] Compilation failure when excluding OGR Formats

2015-12-10 Thread Timothy Astle
I just tried to build the head of the GDAL trunk with the following commented out in the opt file: #INCLUDE_OGR_FRMTS = YES The build fails because during the compilation of ogrutils. The compiler has no idea what GDALGeneralCmdLineProcessor or GDAL_OF_VECTOR are. It appears that gdal.h isn

Re: [gdal-dev] Ogr sqlite spatialite shared caching 2.0.1

2015-12-10 Thread kelly elton
Ah shit. I was trying the sqlite3_ version but I used the wrong case :\ Thanks for the verification and information, it appears to be working. On Thu, Dec 10, 2015 at 1:45 PM wrote: > On Thu, 10 Dec 2015 18:22:09 +, kelly elton wrote: > > I'm just trying to figure out how to turn on SQlite/

Re: [gdal-dev] Ogr sqlite spatialite shared caching 2.0.1

2015-12-10 Thread a . furieri
On Thu, 10 Dec 2015 18:22:09 +, kelly elton wrote: I'm just trying to figure out how to turn on SQlite/Spatialite shared cache in the latest stable version 2.0.1 Before I would just call SPLite3_enable_shared_cache but apparently that's been deprecated and doesn't exist anymore.(as well as S

[gdal-dev] Ogr sqlite spatialite shared caching 2.0.1

2015-12-10 Thread kelly elton
I'm just trying to figure out how to turn on SQlite/Spatialite shared cache in the latest stable version 2.0.1 Before I would just call SPLite3_enable_shared_cache but apparently that's been deprecated and doesn't exist anymore.(as well as SPLite4_enable_shared_cache) It also appears that SQLite3

Re: [gdal-dev] spatialite linking issues

2015-12-10 Thread kelly elton
Thanks, adding a space and a path to the sqlite_i.lib did the trick On Thu, Dec 10, 2015 at 11:14 AM Even Rouault wrote: > Le jeudi 10 décembre 2015 17:00:12, kelly elton a écrit : > > So I'm building on windows > > > > I downloaded the osgeo4w installer and installed the spatialite + sqlite >

Re: [gdal-dev] spatialite linking issues

2015-12-10 Thread Even Rouault
Le jeudi 10 décembre 2015 17:00:12, kelly elton a écrit : > So I'm building on windows > > I downloaded the osgeo4w installer and installed the spatialite + sqlite > libraries. > > I uncommitted these two lines > > SQLITE_INC=-IC:\OSGeo4W\include -DHAVE_SPATIALITE -DSPATIALITE_AMALGAMATION > SQ

[gdal-dev] spatialite linking issues

2015-12-10 Thread kelly elton
So I'm building on windows I downloaded the osgeo4w installer and installed the spatialite + sqlite libraries. I uncommitted these two lines SQLITE_INC=-IC:\OSGeo4W\include -DHAVE_SPATIALITE -DSPATIALITE_AMALGAMATION SQLITE_LIB=C:\OSGeo4W\lib\spatialite_i.lib So when compiling now(which was wo

Re: [gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Even Rouault
Le jeudi 10 décembre 2015 10:41:20, Martin Landa a écrit : > Hi, > > 2015-12-10 10:27 GMT+01:00 Even Rouault : > > And normally ./configure should define HAVE_DIRECT_H in port/cpl_config.h > > only if it is available. > > to be more precise, I am building GRASS against GDAL shipped via > OSGeo4W

Re: [gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Martin Landa
Hi, 2015-12-10 10:27 GMT+01:00 Even Rouault : > Same here. Except when I look at > https://svn.osgeo.org/grass/grass/trunk/raster/r.in.gdal/main.c, I see it is a > G_snprintf() call, so perhaps you use an outdated version ? Or perhaps no, I fixed that some minutes ago by replacing snprintf() by

Re: [gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Jürgen E . Fischer
Hi Even, On Thu, 10. Dec 2015 at 10:27:57 +0100, Even Rouault wrote: > > currently I am working on Windows GRASS builds (using MSYS2 + > > MinGW64). I have still some issue with GDAL which I am not sure how to > > correctly solve: > > > > 1) GDAL has enabled in cpl_port.h > > > > #ifdef HAVE_DIR

Re: [gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Martin Landa
Hi, 2015-12-10 10:27 GMT+01:00 Even Rouault : > And normally ./configure should define HAVE_DIRECT_H in port/cpl_config.h > only if > it is available. to be more precise, I am building GRASS against GDAL shipped via OSGeo4W (which has HAVE_DIRECT_H already defined). I didn't find this header in

Re: [gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Even Rouault
Le jeudi 10 décembre 2015 10:11:19, Martin Landa a écrit : > Hi all, > > currently I am working on Windows GRASS builds (using MSYS2 + > MinGW64). I have still some issue with GDAL which I am not sure how to > correctly solve: > > 1) GDAL has enabled in cpl_port.h > > #ifdef HAVE_DIRECT_H > # i

Re: [gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Martin Landa
Hi, 2015-12-10 10:11 GMT+01:00 Martin Landa : > 3) r.in.gdal > > OBJ.x86_64-w64-mingw32/main.o: In function `dump_rat': > /home/landa/grass_trunk/raster/r.in.gdal/main.c:1601: undefined > reference to `_snprintf' > /home/landa/grass_trunk/raster/r.in.gdal/main.c:1601:(.text.startup+0x1655): > relo

[gdal-dev] direct.h and other Windows issue

2015-12-10 Thread Martin Landa
Hi all, currently I am working on Windows GRASS builds (using MSYS2 + MinGW64). I have still some issue with GDAL which I am not sure how to correctly solve: 1) GDAL has enabled in cpl_port.h #ifdef HAVE_DIRECT_H # include #endif which is old header used by MSVC, modern is dirent.h, right? I