Nik,
weird that the patch didn't work for you. It did for me on a SQLite3
build with -DSQLITE_OMIT_PROGRESS_CALLBACK=1 . I've just reworked it to
amend the commit message and comment not to mention iOS
But https://www.sqlite.org/compile.html doesn't say that this is
recommended, it says it is "recommended for applications that are able
to use them [...]. Not all of these compile-time options are usable by
every application".
And typically you *don't* want to build SQLite3 with SQLITE_THREADSAFE=0
as that "means that SQLite can never be used by more than a single
thread at a time", which would break GDAL multithreaded usage.
Even
Le 12/11/2022 à 04:17, Nik Sands a écrit :
Hi again,
I have now resolved this issue by rebuilding SQLite with the
SQLITE_OMIT_PROGRESS_CALLBACK=OFF
GDAL 3.6.0 will now build successfully with my updated buiild of SQLite.
Sorry to have troubled you with this one.
NB: This may still be worth pursuing within GDAL, since SQLite
explicitly recommend building with this omitted, as per:
https://www.sqlite.org/compile.html
If you still wished to pursue a GDAL fix for possibility of missing
sqlite3_progress_handler, then it’s worth noting that it’s not an iOS
issue, as far as I know, since I was not using iOS default SQLite.
Cheers,
Nik.
On 12 Nov 2022, at 1:51 pm, Nik Sands <[email protected]> wrote:
Hi Even,
Sorry, I should have mentioned that I’m not using the standard
iOS/macOS SQLite (because it does not include RTREE extension which
seems to be required for GDAL).
I’m using a CMAKE compatible SQLite from:
https://github.com/azadkuh/sqlite-amalgamation (which was working
fine with GDAL 3.5.2)
I tried building SQLite with:
-DSQLITE_OMIT_PROGRESS_CALLBACK=OFF
but it logged that it was ignoring this (not sure why, when it works
OK when I specify other options similarly, such as
-DSQLITE_OMIT_DECLTYPE=OFF)
Anyhow…
The patch build of GDAL did not resolve the problem, although the
output is slightly different. I still got this error (re-pasted from
current build, below).
I’m also trying to figure out how to get
SQLITE_OMIT_PROGRESS_CALLBACK disabled in my SQLite build, which may
be a better way to go? Got to figure out the right CMakeLists.txt
changes (in SQLite) for this.
Cheers,
Nik.
Consolidate compiler generated dependencies of target gdal_unit_test
[ 94%] Linking CXX executable gdal_unit_test.app/gdal_unit_test
Undefined symbols for architecture arm64:
"_sqlite3_progress_handler", referenced from:
OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int
(*)(double, char const*, void*), void*) in
libgdal.a(ogrgeopackagetablelayer.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [autotest/cpp/gdal_unit_test.app/gdal_unit_test] Error 1
make[1]: *** [autotest/cpp/CMakeFiles/gdal_unit_test.dir/all] Error 2
make: *** [all] Error 2
On 12 Nov 2022, at 12:45 pm, Even Rouault
<[email protected]> wrote:
Weird. So it would seem the SQLite3 build on iOS lacks
sqlite3_progress_handler()
As this is not critical for operations, I've added a CMake configure
check for the presence of this function to conditionally enable it.
Can you try https://github.com/OSGeo/gdal/pull/6675 ?
Even
Le 12/11/2022 à 02:32, Nik Sands a écrit :
After patching GDAL 3.6.0 for ‘pread64’ issue when building for iOS
(see previous email), the build now progresses to the 100% mark,
but then fails with the _sqlite3_progress_handler error below.
I’m afraid that I don’t even know where to start with this one.
How should I proceed?
Cheers,
Nik.
[100%] Built target check_swq_parser_md5
Consolidate compiler generated dependencies of target
my_test_sqlite3_ext
[100%] Built target my_test_sqlite3_ext
[100%] Built target check_ods_formula_parser_md5
Consolidate compiler generated dependencies of target test_gdal_fuzzer
[100%] Linking CXX executable test_gdal_fuzzer.app/test_gdal_fuzzer
Undefined symbols for architecture arm64:
"_sqlite3_progress_handler", referenced from:
OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int
(*)(double, char const*, void*), void*) in
libgdal.a(ogrgeopackagetablelayer.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [fuzzers/tests/test_gdal_fuzzer.app/test_gdal_fuzzer]
Error 1
make[1]: *** [fuzzers/tests/CMakeFiles/test_gdal_fuzzer.dir/all]
Error 2
make: *** [all] Error 2
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
========================================================
NIK SANDS
Line Tamer | Time Traveller | Space Cadet
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
========================================================
NIK SANDS
Line Tamer | Time Traveller | Space Cadet
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
