Redistributing a Spatialite based application

[ckgoo...@gmail.com]

Hello, this maybe off topic for this list, and if so, apologies. But then again, it might not.

I have written an application for Windows using QT which uses a Spatialite database.  I also need the proj.db and proj_9.dll in my application folder.  I have pulled a whole bunch of dependencies together and have created an MSI which I run on a local virtual Windows machine which is a clean build.

My application runs, and data is being read from my Spatialite database.  For example, I can do an ST_Contains call successfully. This is good.

What is failing is the rendering of any polygons in my map window.

I think this is because I am doing reference frame transformations which uses proj_9.dll but there is some mismatch somewhere in the DLL’s I have pulled together and proj_9.dll is quietly erroring.

In collecting DLL’s, I have also come across:

• Needing to get different version of the same DLL but with different numbers at the end e.g. liblzma.dll andliblzma-5.dll.
• Different versions of a DLL which have a different size e.g. libcurl.dll at 694k or libcurl.dll at 901kb.

And with multiple versions and multiple paths defined in my environment variable, it is a guess as to what version my application uses at runtime on my development machine.

So it is all a bit of a mess really.

Can anyone provide any guidance, or point me to guidance, on how to simplify my system so I can take the guesswork out of trying to get the right dependencies captured in my MSI?  I really need a strategy.

Kind regards,

Chris

[sandro furieri]

Hi Chris,

welcome to DLL hell.
Don't worry, you're certainly not the first to find yourself banging
your head against this kind of problem; it's practically the usual
scenario for those who venture into the swampy and unwholesome terrain
of Windows app development.
plese see: https://en.wikipedia.org/wiki/DLL_hell

Il 2026-01-28 18:29 ckgoo...@gmail.com ha scritto:
> What is failing is the rendering of any polygons in my map window.
> I think this is because I am doing reference frame transformations
> which uses proj_9.dll but there is some mismatch somewhere in the
> DLL's I have pulled together and proj_9.dll is quietly erroring.
>

I'm not sure I understand correctly:
- does everything work fine on your development PC?
- or are there problems with this one too?

> In collecting DLL's, I have also come across:

> * Needing to get different version of the same DLL but with different

> numbers at the end e.g. liblzma.dll andliblzma-5.dll.

> * Different versions of a DLL which have a different size e.g.

> libcurl.dll at 694k or libcurl.dll at 901kb.
>

This all sounds downright scary; it's a clear sign that you're not
in control of the situation, and that you're essentially at the mercy
of pure chance.
It doesn't seem like a reasonable recipe for stability and reliability.

> Can anyone provide any guidance, or point me to guidance, on how to
> simplify my system so I can take the guesswork out of trying to get
> the right dependencies captured in my MSI? I really need a strategy.
>

First of all, try using Dependency Walker; it's an open-source tool
that tells you which DLLs your app depends on.
It's not the easiest to use, but it can help you to better understand
which DLLs you're actually using on your development PC.
https://www.dependencywalker.com/

However, the best solution to definitively escape from DLL hell is to
give up using DLLs altogether, or at least limit it to the bare minimum.
On Windows, the easiest and safest way to distribute apps that rely on
many open source libraries is to use static linkage as much as possible.
By the way, there's also an additional advantage: a monolithic EXE
statically linked doesn't require any installation process at all;
you just copy it somewhere and it immediately works without any
further complications.

I personally chose the static linkage approach for SpatiaLite's
Windows binary distributions, and honestly, I've always been very
happy with it; stable and secure apps, no installation complexity.
If you're interested in learning more, you can find all my personal
recipes for Windows here:

Win32: https://www.gaia-gis.it/gaia-sins/mingw32_how_to.html

Win64: https://www.gaia-gis.it/gaia-sins/mingw64_how_to.html

bye,
Sandro

[ckgoo...@gmail.com]

Hi Sandro,

Thanks for your swift reply.

My application works fine on my development machine. And I'm doing coordinate transformations which I think uses proj_9.dll. But I seem to remember reading that this DLL fails silently. That is, if it can't do something because a dependency isn't present, it will return 0 or null rather than throw an error. So when I transform my polygons ready for drawing it is probably returning nothing and hence my map is blank when I run it on my virtual just because a dependency isn't present.

I've got dependencies rather than dependency walker and will work with that for now. I'll also play with some Python scripts to try and automate the task a bit. Static linking sounds like a good idea but also isn't an easy solution as I'd have to rebuild QT as static libraries - if I understand things right.

But the good news is that I now do see a way forward out of DLL hell.

Best, Chris

--
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 visit https://groups.google.com/d/msgid/spatialite-users/311cfee6f6bdb290a3f361c76766f5c0%40lqt.it.

[sandro furieri]

Il 2026-01-28 23:57 ckgoo...@gmail.com ha scritto:
> My application works fine on my development machine. And I'm doing
> coordinate transformations which I think uses proj_9.dll.
>

Hi Chris,

With the latest versions of the PROJ library, simply installing the DLL
isn't enough.
It's absolutely essential to also install the corresponding support DB,
which contains all the parameters needed for geodesic transformations.
This is simply a SQLite DB named "proj.db"; the easiest thing on Windows
is to install it in the same folder as the DLL.
This is an absolutely critical point; have you checked carefully?

Caveat: Each PROJ version has its own specific "proj.db"; haphazardly
mixing DLL and DB from different versions is a sure recipe for disaster.

> Static linking sounds like a good idea but also isn't an easy

> solution as I'd have to rebuild QT as static libraries.
>

I personally use wxWidgets instead of QT, and it's very easy to
compile on Windows and supports static linking.
I have no direct experience with QT, but I found two links that
might be helpful to you:

https://wiki.qt.io/Building_Qt_Desktop_for_Windows_with_MinGW

https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW

If I understand correctly, it should be possible to compile QT
from source on Windows, and it should also be possible to
statically link the resulting library.

bye Sandro

[ckgoo...@gmail.com]

Hello Sandro and all,

Winston Churchill said, "If you are going through hell, keep going." Well, I am still in DLL hell but feel I am close to escaping.

My QT C++ application directly calls the PROJ library to do transformations from SRID 4326 to the Lambert projection before converting to screen coordinates. On my development machine this has worked fine - I have a proj.dll and its proj.db in my executable folder.

When I try to deploy to a virtual (clean) machine I copy lots of DLL's to the same folder as my executable. I'll list the files at the end of this email. They include mod_spatialite, proj.dll (with its .db) and others. However, I was getting a conflict with libssl-3-x64.dll and libcrypto-3-x64.dll because my mod_spatialite and proj DLL's wanted these but different versions.

Taking guidance from Gemini, I used vcpkg with a line:
vcpkg install gdal[libspatialite,openssl]:x64-windows
vcpkg is a tool with MS Visual Studio 2022. By some kind of magic it goes and gets source code and compiles the DLL's I need, including spatialite.dll (which I rename to mod_spatialite.dll", proj.dll, proj.db, libssl and lib cypto. They are all self-consistent so I don't get version conflicts.

So I copy them all into my executable folder but my LoadExtension call fails when loading mod_spatialite. I get one step further by naming the specific entry point:
sql = "SELECT load_extension('mod_spatialite', 'spatialite_init');";
Gemini's reasoning is that the default entry point has been changed because I built it all using this vcpkg.

With this I get an error of "Error during initialisation". Yet I believe I have all my DLL's and proj.db is in the right place.

Any thoughts on whether this problem can be fixed? I do get partial success using an entry point of spatialite_init_ex but the behaviour of the results I get back from Spatialite queries isn't correct as I get many results back instead of an expected single result.

Best,
Chris


File list:
freexl-1.dll
gdal.dll
geos.dll
geos_c.dll
geotiff.dll
gif.dll
hdf5.dll
hdf5_hl.dll
iconv-2.dll
jpeg62.dll
json-c.dll
Lerc.dll
libcrypto-3-x64.dll
libcurl.dll
libexpat.dll
liblzma.dll
libpng16.dll
libpq.dll
libsharpyuv.dll
libssl-3-x64.dll
libwebp.dll
libxml2.dll
minizip.dll
mod_spatialite.dll
netcdf.dll
openjp2.dll
pcre2-8.dll
proj.db
proj_9.dll
qhull_r.dll
sqlite3.dll
szip.dll
tiff.dll
tinyxml2.dll
zlib1.dll
zstd.dll

-----Original Message-----
From: spatiali...@googlegroups.com <spatiali...@googlegroups.com> On Behalf Of sandro furieri
Sent: 29 January 2026 08:37
To: spatiali...@googlegroups.com
Subject: Re: [SpatiaLite-Users] Redistributing a Spatialite based application

--
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 visit https://groups.google.com/d/msgid/spatialite-users/d21713fba7c9cedc0caa0427dd2c273e%40lqt.it.

[sandro furieri]

Il 2026-02-02 11:47 ckgoo...@gmail.com ha scritto:
> I have a proj.dll and its proj.db in my executable folder.
>

Hello Chris,

Note: the effects of the absence (or presence of an
inconsistent version) of proj.dll and proj.db are very
different and easily distinguishable:

a) a missing or mismatching proj.dll causes a load error;
the extension module cannot be loaded and the call to
load_extension() fails.

b) a missing or mismatched proj.db will instead cause
runtime problems.
The extension module will load correctly, but the
first call to ST_Transform() will give incorrect
results.


> ... including spatialite.dll (which I rename to
> mod_spatialite.dll"
>

This is definitely wrong.
libspatialite and mod_spatialite are two completely
different objects and you can't interchange them.

- libspatialite is a classic dynamic library, and is
specifically designed to be linked directly into an
executable developed in C or C++

- mod_spatialite on the other hand is not a library at
all, it's a dynamically loaded module made specifically
to be loaded by SQLite's load_extension().

> With this I get an error of "Error during initialisation"

> ... the default entry point has been changed
>

This is the obvious result of the above; your fake mod_spatialite
doesn't have the expected entry point at all, precisely because
it's just a poorly disguised libspatialite.

Given your context, I think the simplest solution for you is to
change the way you load SpatiaLite.
Since you don't have a real mod_spatialite, forget about using
SQLite's load_extension().
To initialize libspatialite in the classic C/C++ way, you can
take some inspiration from the followind code snippet:

-------------------------------------------------------
Start - Initialing
-------------------------------------------------------
sqlite3 * sqlite;
const char *path;
int mode;
void *cache;
int ret;

// opening the DB connection
ret = sqlite3_open_v2(path, &sqlite, mode, NULL);
if (ret)
; // do some error handling

// properly setting SQLite
ret = sqlite3_exec (sqlite,
"PRAGMA trusted_schema=0",
NULL, NULL, NULL);
if (ret != SQLITE_OK)
; // do some error handling
ret = sqlite3_exec (sqlite,
"PRAGMA foreign_keys=1",
NULL, NULL, NULL);
if (ret != SQLITE_OK)
; // do some error handling

// initialing SpatiaLite
cache = spatialite_alloc_connection();
spatialite_init_ex(sqlite, cache, 0);

// properly initialize the SpatiaLite DB
ret = sqlite3_exec (sqlite,
"SELECT InitSpatialMetadataFull()",
NULL, NULL, NULL);
if (ret != SQLITE_OK)
; // do some error handling
-------------------------------------------------------

End - Closing and freeing resources
-------------------------------------------------------
sqlite3_close(sqlite);
spatialite_shutdown();
spatialite_cleanup_ex(cache);
-------------------------------------------------------

best regards.
Samdrp

[ckgoo...@gmail.com]

Hello Sandro,

I have success. I think.

Thanks for saving me from further time mixing up mod_spatialite.dll and spatialite.dll. I had a rethink and realised that my c:/OSGeo4W folder contained mod_spatialite.dll and all other files I needed. I was able to get all the dependencies I need from this folder structure and I've now compiled my application, wrapped it in a install shield, and deployed it to my virtual device.

And it runs without obvious error. No warnings about missing dependencies or absent entry points. And functionally it is more or less there as there is a map displayed and I can move around successfully and get info on my location.

The odd thing is that some feature that toggles me between country and state view fails although it is fine on my dev machine. I think this now puts me into a new world of how to debug when you can't use an IDE to do it with. I don't think this is a Spatialite problem and I'm sure Gemini can give me guidance on how to do this with my setup.

Feel like I've made a step forward. Thanks for your help.

Best,
Chris

-----Original Message-----
From: spatiali...@googlegroups.com <spatiali...@googlegroups.com> On Behalf Of sandro furieri
Sent: 02 February 2026 12:19
To: spatiali...@googlegroups.com
Subject: Re: [SpatiaLite-Users] Redistributing a Spatialite based application

--
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 visit https://groups.google.com/d/msgid/spatialite-users/3ecdf52e7015ebc1af3bbd49b51703e8%40lqt.it.