[gdal-dev] Problem to compile in Lucid with Spatialite 3.0 and gdal 1.9

[a.furieri at lqt.it]

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