How to build libspatialite-5.0.1 for iOS

Skip to first unread message


Aug 2, 2021, 2:51:42 AM8/2/21
to SpatiaLite Users
Hi All,

I tried it's working for 4.4.0-RC1.

Is there way to find out which geos, proj, sqlite version is compatible to v5.0.1? I tried few versions but it's giving below error.
checking for library containing GEOSFrechetDistance_r... none required
checking minizip/unzip.h usability... no
checking minizip/unzip.h presence... no
checking for minizip/unzip.h... no
configure: error: cannot find minizip/unzip.h, bailing out


Aug 2, 2021, 4:07:08 AM8/2/21
On Sun, 1 Aug 2021 23:51:41 -0700 (PDT), Vaibhav wrote:
> Hi All,
> I tried [1] it's working

your problem clearly is that you have no minizip installed.

this one is a small library required by 5.0.1 supporting
direct read access to compressed zipfiles.
it's usually supported as a standard system package by
almost all Linux distributions, but I'm not aware if
it's available on MacOS too.

in any case building minizip from its sources isn't
difficult at all; you could find someway interesting
my own build recipe for Windows that shouldn't be
too much hard to adapt for MacOS

bye Sandro


Aug 2, 2021, 11:32:14 AM8/2/21
to SpatiaLite Users
I have installed minizip  through homebrew but still getting error.

checking for minizip/unzip.h... no
configure: error: cannot find minizip/unzip.h, bailing out


Aug 2, 2021, 12:15:07 PM8/2/21
to SpatiaLite Users
I am using this makefile -

Aug 2, 2021, 1:14:28 PM8/2/21
On Mon, 2 Aug 2021 09:15:07 -0700 (PDT), Vaibhav wrote:
> I am using this makefile - [7]

I see that you are keeping disabled a lot of useful

--enable-freexl=no --enable-libxml2=no --disable-rttopo

I presume that the optimal solution for you should be
to disable minizip as well:


I suppose that on a smartphone the capability to
read shapefiles directly from within a compressed
zipfile will be of very little interest.

bye Sandro


Aug 2, 2021, 2:45:47 PM8/2/21
to SpatiaLite Users
Hi Sandro

I have disabled --enable-freexl=no --enable-libxml2=no --disable-rttopo because i got errors while I was building static file. I don't know exact use cases of this variables. ☹️
After setting --enable-minizip=no got below error

Undefined symbols for architecture armv7:
  "_sqlite3_enable_load_extension", referenced from:
      _gaia_sql_proc_execute in libspatialite.a(stored_procedures.o)
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [demo1] Error 1
make[3]: *** [install-recursive] Error 1
make[2]: *** [install-strip] Error 2

Do you I required specific version of proj, geos, sqlite version to build libspatialite-5.0.1?
When i set proj-8.0.1 then i got this error
checking for curl-config... /usr/local/opt/curl/bin/curl-config
        found libcurl version 7.78.0
checking for curl_global_init in -lcurl... no
configure: error: curl not found. If wanting to do a build without curl support (and thus without built-in networking capability), explictly disable it with --without-curl

Is there any other way to use libspatialite-5.0.1 in iOS app?

Aug 3, 2021, 3:46:29 AM8/3/21

I'm sorry to say this, but I've the impression that you are
just attempting to blindly skip build issues one at each time
without any real effort for understanding what's really
happening, and that's not good at all.

first of all, we absolutely need to clear up a dangerous

"Do you I required specific version of proj, geos, sqlite
version to build libspatialite-5.0.1?"

absolutely no, because 5.0.1 is able to interact
with a wide range of different versions.
but you must necessarily update your super-Makefile
so to be able to adequately support the more recent
versions of all required libraries.

each time that you'll get some compilation error
the right action cannot be "gosh, I've to disable
something" but instead "why this is failing ?
what I'm expected to correct or integrate so
to resolve this issue ?"

general remark: your super-Makefile is not at all
bad, but is surely become obsolete or inaccurate
in many ways. just few exemples:

- you are keeping disabled libxml2, but I'm unable
to see any good reason for doing such a thing,
because libxml2 has no further dependency and
usually builds without any problem.
I suppose that you simply have to add few lines
in your super makefile in order to build it
then enabling it.

- the same is for librrtopo, that just depends
on libgeos.

- your super makefile configures PROJ-6.3.0 that
is nowadays badly outdated, the current version
being 8.1.0
note: recent versions of PROJ strictly require
to be supported by libcurl and libgeotiff,
and both them are lacking in your configuration

- final remark: an error message like "undefined
symbol _sqlite3_enable_load_extension" usually
means that libsqlite3 was incorrectly built by
disabling dynamic extensions.


conclusions: your porting of libspatialite for
iOS is surely affected by several troubles of
different origins that patiently requiring
to be solved one at each time.

prepare yourself for a long debugging/updating
session patiently fixing a library after the

useful resources: please carefully study my build
recipes for MinGW on Windows [1] [2].
yes, iOS actually is a very different platform,
but they'll surely help you to better understand
the complex chain of dependencies and the more
recent specific requirements of each library.


bye Sandro


Aug 3, 2021, 9:19:58 AM8/3/21
to SpatiaLite Users
Thanks Sandro I will check this.
Reply all
Reply to author
0 new messages