HI Frank and Even, I confirm that Even is absolutely right: using the "amalgamation" on Linux is strongly discouraged, and may pose several problems if not properly handled. Just few technical clarifications: a) libspatialite expects to link an external lisqlite3; there is absolutely nothing extraordinary in this, it's the standard behavior expected on Linux. b) on the other side, libspatialite-amalgamation internally includes a private copy of the most recent sqlite sources: but in order to avoid any obnoxious interference with the "system" libsqlite, any link symbol exported by this "internal private copy" is purposely masked (renamed). Please note well: 1) when the "external/system" libsqlite is intended to be used, C/C++ sources must include the corresponding standard header-file: #include <sqlite3.h> 2) but when the "private/internal" libsqlite is intended to be used, C/C++ sources must absolutely include the header-file installed by libspatialite, and not the "standard" one: #include <spatialite/sqlite3.h> A -DSPATIALITE_AMALGAMATION conditional macro is usually supported by any spatialite-aware package, in order to make configuration as painless as possible: and GDAL/OGR supports this SPATIALITE_AMALGAMATION macro.
So, if for any good reason you absolutely want to build GDAL on Linux using the "amalgamation" (a strongly discouraged option IMHO), you can try using the following recipe: export "CPPFLAGS=-DSPATIALITE_AMALGAMATION=1" ./configure --with-spatialite=/usr/local make bye Sandro _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
