[Python-modules-team] Bug#910240: python3-django: GeoDjango incorrectly initialize spatialite (Error: /usr/lib/x86_64-linux-gnu/mod_spatialite.so: undefined symbol: sqlite3_spatialite_init)

Sebastiaan Couwenberg sebastic at xs4all.nl
Wed Oct 3 20:19:54 BST 2018


On Wed, 03 Oct 2018 20:42:42 +0200 Petter Reinholdtsen wrote:
> According to sebastic on #debian-gis, the way to load spatialite changed
> in version 4.2, and now the correct way to load the library is to use
> "SELECT load_extension('mod_spatialite');", while the GeoDjango database
> backend try to load it using the full path to the library file, which
> for some reason is no longer working.

For reference see the upstream documentation:

 https://www.gaia-gis.it/fossil/libspatialite/wiki?name=mod_spatialite

To quote the "What's new in mod_spatialite" section:

"
 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:

  * libspatialite (.so, .dll, .dylib and so on): a genuine classic
    shared library.
    It will always depend on some external libsqlite3, and is uniquely
    intended to be used by stand-alone applications (such as e.g.
    spatialite or spatialite_gui).
    You'll never be able to successfully load this libspatialite shared
    library as a dynamic extension via the SELECT load_extension
    mechanism, simply because it doesn't declare the required
    conventional interface.

  * mod_spatialite (.so, .dll, .dylib and so on): this is simply
    intended as pure loadable module lacking any explicit SQLite3
    dependency.
    You'll never be able to directly link this mod_spatialite shared
    library following the classic way, because it doesn't declare any
    external link symbol except that a single one: i.e. the conventional
    interface. The unique possible way to load and activate this module
    is by calling a SELECT load_extension SQL statement.
"



More information about the Python-modules-team mailing list