Bug 1048587

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.