Le mardi 30 juin 2015 13:40:33, Radim Blazek a écrit : > On Tue, Jun 30, 2015 at 1:22 PM, Even Rouault > > <even.roua...@spatialys.com> wrote: > > Le mardi 30 juin 2015 13:17:50, Paolo Cavallini a écrit : > >> Il 30/06/2015 11:15, Richard Duivenvoorde ha scritto: > >> > Yep, confirmed here on a fresh Debian self compiled version. > > > > Might be related to the issue discussed at > > http://lists.osgeo.org/pipermail/gdal-dev/2015-May/041796.html > > and > > http://lists.osgeo.org/pipermail/qgis-developer/2015-May/037820.html > > Thanks Even, > > we can probably get around this using mutex in QgsGdalLayerItem if > Spatialite is < 4.2. > Can we get somehow SPATIALITE_412_OR_LATER or bSpatialiteGlobalLoaded > from GDAL API or its headers ?
Radim, I can't think a way of getting those internal details from the outside. However if the (external) spatialite version available when compiling QGIS is < 4.2, then it is very likely that the one used when compiling GDAL is also < 4.2 The configure test used by GDAL is: AC_CHECK_LIB(spatialite,spatialite_target_cpu,SPATIALITE_412_OR_LATER=yes,SPATIALITE_412_OR_LATER=no) You could also fallback to runtime checks with SELECT spatialite_version() This assumes a setup where not too odd things happen, i.e. compiling with a version and updating it between compilation of various software components. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer