NEXTGEN RC1 - loadable modules for Windows

[Alessandro Furieri]

Hi list,

this further announcement can easily interest many Java, Python, C# etc developers.

the pre-built loadable modules for Windows are now available for downloading:

http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-x86/spatialite-loadable-modules-NG-RC1-win-x86.7z

http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-amd64/spatialite-loadable-modules-NG-RC1-win-amd64.7z

please read the following tech note for more detailed infos.

https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Lodable+Modules+in+5.0

happy testing,

Sandro

[David Anderson]

Yeah!
What timing.  I was wondering if the modules were available.  I downloaded the

 about 10 minutes before this post arrived.  Going to test them out today.

[David Anderson]

I have run into a issue when trying to load the extension with Python.

First, the posted instructions worked fine.   I double tested with another 64 bit Sqlite package.  It too loaded the extensions fine.  So the Path is configured correctly.

When I try in Python, I get the error message shown in the image.

I tried several flavors of Python, including Anaconda2, Anaconda3 and the Python that comes with ArcGIS Pro (3.5?)

I tried upgrading the sqlite3.dll to the one supplied in the Spatialite download package.

I tried in command line, in Spyder and in Jupyter interfaces,

Nothing worked.  Same message every time.

If anyone else has figured out how to load the new module in Python, please post the solution.

BTW I'm working in Windows 10, 64 bit.

Thanks,

David

[a.fu...@lqt.it]

On Thu, 6 Aug 2020 14:06:58 -0700 (PDT), David Anderson wrote:
> If anyone else has figured out how to load the new module in Python,
> please post the solution.
>
> BTW I'm working in Windows 10, 64 bit.
>

Hi David,

the symbol
_ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev
is required by proj-19.dll and is defined by libstdc++-6.dll (C++
runtime)

it seems that this DLL has not been correctly loaded by Python, or it
may probably be that there is some conflict with a different version
of the C++ runtime DLL

bye Sandro

[David Anderson]

Sandro,

Thanks for that hint.  I assumed that you are using the most up to date C++ version.  This prompted me to install the latest Python version,3.8.5, which used MSC 1924.   Success!  The older version 3.7.6 MSC 1916 is the one that didn't work.

Thanks for the prompt response and all the work into this project.

[Pedro Camargo]

I think this might be a bigger problem, though.

According to Python's documentation (https://devguide.python.org/#status-of-python-branches), Python 3.6's end of life is scheduled for the end of 2021 and for 3.7 is scheduled for mid 2023. Is there any way to make the loadable binaries compatible with those Python versions as well?

Cheers,
Pedro

---- On Fri, 07 Aug 2020 08:15:00 +1000 David Anderson <david.and...@gmail.com> wrote ----

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/60633b3e-063d-42ef-b3a7-b8267d605ad1o%40googlegroups.com.

[br...@frogmouth.net]

I think it is more how the python was build for Windows, rather than which specific version it is. 

Brad

[Pedro Camargo]

It most certainly is, Brad!

The point is that there are prescribed standards for building each version of Python, which sets the standard for all compiled code to run with it.

Cheers,

Pedro

---- On Fri, 07 Aug 2020 09:01:38 +1000 <br...@frogmouth.net> wrote ----

I think it is more how the python was build for Windows, rather than which specific version it is. 

Brad

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/e4b8478f-3c3f-4bc6-9078-668809bcf795%40email.android.com.

[Pac]

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?

Thanks in advance,

Paco.

[a.fu...@lqt.it]

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

[Pac]

Hi Sandro,

Thank you for your explanation. I saw proj.db and inferred its mandatory inclusion besides libproj-19, but I didn't know the innard requirements SQLite imposes to its extensions.

Bye, Paco.