Description of problem: The spatialite cannot be executed because it was compiled with a different version of sqlite. The spatialite was compiled on 2013-Aug, and sqlite was updated on 2013-Dec Version-Release number of selected component (if applicable): libspatialite-4.1.1-2.fc20.i686 spatialite-gui-1.7.1-2.fc20.i686 spatialite-tools-4.1.1-2.fc20.i686 sqlite-3.8.2-1.fc20.i686 sqlite-devel-3.8.2-1.fc20.i686 How reproducible: Every time sqlite3 updated and spatialite not recompiled to match the version. Steps to Reproduce: 1. Install libspatialite and spatialite-tools from current repository (2014-01-05). 2. execute spatialite Actual results: SQLite header and source version mismatch 2013-12-06 14:53:30 27392118af4c38c5203a04b8013e1afdb1cebd0d 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668 Expected results: Execute correctly the application. Additional info:
I contacted the author, as I'm not sure why this is necessary.
What's the status here, did you get any reply from the author?
Yes, thanks for reminding me! Please find the author's response below. 4.2 is in the RC state now. That means for now, that I must recompile spatialite-tools on sqlite updates. """ I've checked this issue on FC17 and FC18: and I can (partially) confirm that a problem exists, but it's strictly confined to the spatialite.c source alone. short recall: the spatialite CLI front-end simply is a direct derivative of the original sqlite3 front-end. the main difference between them is in that the spatialite CLI tool will automatically load the extension, thus avoiding to the user the annoyance to explicitly call: SELECT load_extension(path-to-so); unhappily, the sqlite3 own code internally includes somewhere a formal check ensuring that the dynamically loaded .so should exactly correspond to the same version declared by the header file used at compile time. and rather obviously the spatialite own code inherits this feature from the original implementation. any other tool (e.g. spatialite_osm_map or spatialite_gui) seems to be completely immune from this issue; all them will simply load the current .so without raising any version complaint. future plans: - there is no real reason to continue supporting the spatialite CLI frontend in the long term. - it mainly is a strict derivative of the standard sqlite3 CLI frontend; the unique added-values is in silently/automatically loading the spatialite extension and in supporting few more useful "dot macro" commands such as .loadshp, .dumpshp, .elemgeo and friends. PROS: using spatialite CLI instead of sqlite3 CLI is a little bit simpler, and supports more interesting options often useful when executing very complex SQL scripts (e.g. directly importing or exporting Shapefiles from the SQL script itself). CONS: sqlite3 will obviously evolve during time; but spatialite will not directly benefit from any new cool feature because it's now kind of a fork. syncing from time to time the sources of spatialite and sqlite3 CLI is a boring, time consuming, error prone and substantially frustrating task. the most recent evolutions of both libsqlite3 and libspatialite make really simpler loading a dynamic extension; just executing this simple SQL statement is all what is needed: SELECT load_extension('mod_spatialite'); so the real problem is in re-implementing all "dot macro" features as genuine SQL functions directly supported by libspatialite. once we've accomplished this task we could safely stop supporting the spatialite CLI tool, simply because the standard sqlite3 front end will then be enough to represent a complete replacement. last but not least, implementing all the old "dot macro" features as real SQL functions will certainly be a good new for many developers using libstatialite directly from python, java or C# timeline: the release of v.4.2 has already been to longly delayed due to cross comp ability issues related to the first release of the brand new librasterlite2. my immediate plans are to release ASAP both librasterlite2 and libspatialite 4.2 as they currently are. but the next to come 4.3 will certainly support all required SQL functions intended to be a full replacement for the old "dot macro" CLI commands; so I imagine that spatialite-tools 4.2 will surely be the last version including the spatialite CLI frontent, and starting since 4.3 this component should be definitely removed from spatialite-tools. """
(In reply to Volker Fröhlich from comment #3) > Yes, thanks for reminding me! > > Please find the author's response below. 4.2 is in the RC state now. That > means for now, that I must recompile spatialite-tools on sqlite updates. > [SNIP] Thanks a lot for that very useful Volker (and the same to the author)! :)
...that very useful /information/...
spatialite-tools-4.1.1-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/spatialite-tools-4.1.1-3.fc19
spatialite-tools-4.1.1-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/spatialite-tools-4.1.1-3.fc20
spatialite-tools-4.1.1-3.fc20 works
Package spatialite-tools-4.1.1-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spatialite-tools-4.1.1-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7149/spatialite-tools-4.1.1-3.fc20 then log in and leave karma (feedback).
spatialite-tools-4.1.1-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
spatialite-tools-4.1.1-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.