[gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

[Even Rouault]

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 <nik at nixanz.com> 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 
>>> <even.rouault at spatialys.com> 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
>>>> gdal-dev at lists.osgeo.org
>>>> 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
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>> ========================================================
>> NIK SANDS
>> Line Tamer | Time Traveller | Space Cadet
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221112/fad940f5/attachment-0001.htm>