On Thu, 13 Aug 2020 02:04:45 -0700 (PDT), Pac wrote:
> Hi Sandro,
>
> I've just started testing
> spatialite-loadable-modules-NG-RC1-win-amd64
> on Windows 10 with .Net Core 3.1 and System.Data.SQLite.Core
> 1.0.113.1, and so far, so good.
>
> I've found with Dependency Walker that mod_spatialite.dll (and
> libproj-19.dll, by the way) has a dependency on libsqlite3-0.dll,
> which I think should be replaced with a newer version when a new
> SQLite version gets published.
>
> Is that dependency really necessary now, given that in version 4.3.0a
> wasn't needed?
>
Hi Pac,
many relevant things have changed since version 4.3.0
1. spatialite now supports KNN, and KNN implementation is fully
based on sqlite3_rtree_query_callback(), that is part of the
R*Tree module of SQLite.
https://www.sqlite.org/rtree.html
unhappily this function is only declared in sqlite3.h,
whilst it completely lacks on sqlite3ext.h, the header
file usually intended for loadable modules.
so, in order to support KNN directly linking libsqlite3
is absolutely required.
a possible workaround it could be suppressing any KNN
support in mod_spatialite, but such a solution will
directly lead to the very unpleasant situation of
a gelded loadable module missing some functionality.
2. recent versions of libproj depends on libsqlite3,
because now PROJ requires many critical geodesic
data stored in a companion SQLite DB (you'll
find a copy into the binary distibution for
Windows: it's named proj.db)
here there is no possible workaround;; the "special
interface" to SQLite defined in sqlite3ext.h can only
support the loadable module itself, but not any
other depending library (as it's the case of PROJ),
that absolutely must be linked to libsqlite3 in
the classic way (i.e. statically or dynamically).
bye Sandro