Not logged in


Dynamically loading SpatiaLite as an extension module

Theoretical foundations

Technically speaking, SpatiaLite simply is an extension module adding Spatial processing capabilities to SQLite.
Consequently some appropriate mechanism allowing to load both binary libraries (libsqlite3 and libspatialite) then properly registering within SQLite3 the many extended Spatial SQL functions implemented by SpatiaLite is a strictly required task.
A further complication should be taken in proper debt; libspatialite isn't a simple stand-alone self-contained library and depends on several further libraries (libgeos, libproj, libxml2 and so on).

There are several possible alternative paths leading to this final goal:
Silly oddities (to be carefully avoided):

Dynamic loading: how it works

libsqlite3 has the capability to dynamically load extension modules. This feature is available as a C-language API, but is available as a special SQL function as well:
SELECT load_extension('mod_spatialite');
This SQL function make elementary simple (and absolutely language independent) the problem of loading any possible extension; you are simply expected to execute a rather trivial SQL statement in order to load an external extension only when it's actually required.

Loadable extension anatomy:
Common failure causes:

What's new in mod_spatialite

You'll probably be already accustomed to load SpatiaLite as a dynamic extension; but any previous version before 4.2 made no real distinction between loadable modules and general-purpose shared libraries.
As we painfully learned by direct on-the-field experience, this apparently simpler configuration caused lot of troubles: instabilities, sudden crashes and so on. Making a clearer distinction between a general-purpose shared library and a pure loadable module seems to be the definitive solution.
Exactly here is the radical innovation introduce starting since version 4.2; now SpatiaLite is distributed in two alternative flavors: