PS. Apologies - my last email (below) was premature and resulted from a lack
of effort on my own part.
I’ve solved this lastest issue now.
I don’t need Python bindings in this case, so the easiest solution (instead of
installing and/or pointing cmake to a compatible Python environment) is of
course just to add the following to my cmake command:
-DBUILD_PYTHON_BINDINGS=OFF
So my current cmake command for macOS now looks like this:
cmake -DBUILD_PYTHON_BINDINGS=OFF
-DSQLITE3_INCLUDE_DIR=$HOME/build/include
-DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.a
-DCMAKE_INSTALL_PREFIX=$HOME/build -DCMAKE_BUILD_TYPE=Release ..
This results in a successful cmake, and then a successful build.
Thanks again to Even and others for the advice to get me this far. I expect I
will have more questions later when I try to build for iOS. :-)
Cheers,
Nik.
> On 4 Jul 2022, at 12:16 pm, Nik Sands <[email protected]> wrote:
>
> Hi Even,
>
> Thanks for the suggestions. I am now using '$HOME' instead of ‘~’. I’m
> using static libraries instead of dynamic libraries because my goal is to
> build GDAL for iOS once I get the process working for macOS and my
> understanding is that I cannot use dynamic linking in an iOS app (except for
> OS-bundled libraries).
>
> I’ve now attempted to build this way (using custom-built SQLite, as explained
> earlier):
>
> cd gdal-{VERSION}
> rm -r build
> mkdir build
> cd build
> cmake -DSQLITE3_INCLUDE_DIR=$HOME/build/include
> -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.a
> -DCMAKE_INSTALL_PREFIX=$HOME/build -DCMAKE_BUILD_TYPE=Release .. >log.txt 2>&1
>
> I found that it fails if I don’t include: -DCMAKE_BUILD_TYPE=Release
>
> Ignoring the CMake error log, as advised, and now just scanning sdout and
> stderr instead, I find that I get the following at about half-way through the
> output:
>
> ==========
> -- Found BISON: /usr/bin/bison (found version "2.3")
> Traceback (most recent call last):
> File
> "/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/swig/python/get_suffix.py",
> line 1, in <module>
> from setuptools.command.build_ext import EXTENSION_SUFFIXES;
> print(EXTENSION_SUFFIXES[0])
> ImportError: cannot import name 'EXTENSION_SUFFIXES'
> -- Target system: Darwin
> ==========
>
> I don’t really know where to go from here.
>
> Cheers,
> Nik.
>
>> On 1 Jul 2022, at 7:22 pm, Even Rouault <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Nik,
>>
>> regarding the build isssue with Mac system sqlite3, I've filed this as
>> https://github.com/OSGeo/gdal/issues/6011
>> <https://github.com/OSGeo/gdal/issues/6011>
>>
>> regarding your other "Configuring incomplete, errors occurred!" issue, I've
>> found that generally the CMakeOutput.log and CMakeError.log files aren't the
>> best way to spot the issue. They contain a lot of "normal" errors such as
>> the one with iconv, that are due to trying to detect features available or
>> not available in the build environment, so it is expected that some
>> detections fail. You must have another issue, which is in the standard error
>> stream of the "cmake" invokation
>>
>> Run "cmake .. 2>&1 >log.txt" and look for "error" in log.txt
>>
>> You may also want to try to link to the dynamic library of libsqlite3 rather
>> than the static one (static linking is always more difficult to accomplish),
>> so something like -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.dylib
>>
>> I would also avoid using the '~' character for values of CMake variables and
>> rather use $HOME. On my Linux shell, I see the values in the CMakeCache.txt
>> are not expanded to full paths, and I doubt CMake will do it by itself.
>>
>> Even
>>
>> Le 01/07/2022 à 10:58, Nik Sands a écrit :
>>> Thanks again for all the replies and advice. I should have provided more
>>> context around my initial query about building GDAL with cmake on macOS.
>>> So here goes… (this is quite long, so bear with me…)
>>>
>>> My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as
>>> well as for macOS on Intel). I can then combine them into a fat library
>>> and use that in my project (which is what I've been doing successfully for
>>> GDAL 2.2.2 for some time). GDAL 3.6 isn't yet released, so I'm working
>>> with 3.5 for now in order to get my build process right.
>>>
>>> I believe that for iOS, I cannot use any 'homebrew' or 'macports' packages
>>> installed in /usr/local, etc, as dependencies for the GDAL build. They
>>> will likely work for macOS, but not for iOS. Therefore I will need to
>>> build any dependencies manually and install to another location (for both
>>> iOS and macOS), where they do not already exist in the standard macOS/iOS
>>> SDK locations (or where the Apple-supplied libraries in those SDK locations
>>> are otherwise incompatible with GDAL - see SQLite notes below). For any
>>> such dependencies, I plan to install them in ~/build (as I did previously
>>> for GDAL 2.2.2).
>>>
>>> So I'm starting out building simply for macOS, but trying to use a similar
>>> technique to what I hope to use for iOS (after I get it working for macOS).
>>>
>>> So with all that background, I will now start at the beginning of my
>>> attempts to build GDAL 3.5 using a method that I hope will also work for
>>> iOS...
>>>
>>> The GDAL cmake hints page says to do this:
>>>
>>> cd gdal-{VERSION}
>>> mkdir build
>>> cd build
>>> cmake ..
>>> cmake --build .
>>> cmake --build . --target install
>>>
>>> When I run this as-is, the 'cmake ..' succeeds, but the 'cmake --build .'
>>> fails at the 82% mark with this output:
>>>
>>> ==========
>>> [ 82%] Building CXX object
>>> ogr/ogrsf_frmts/sqlite/CMakeFiles/ogr_SQLite.dir/ogrsqlitedatasource.cpp.o
>>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/ogr/ogrsf_frmts/sqlite/ogrsqlitedatasource.cpp:733:21:
>>> error: use of undeclared identifier 'sqlite3_enable_load_extension'
>>> if( sqlite3_enable_load_extension(hDB, 1) == SQLITE_OK )
>>> ^
>>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/ogr/ogrsf_frmts/sqlite/ogrsqlitedatasource.cpp:746:21:
>>> error: use of undeclared identifier 'sqlite3_load_extension'
>>> if( sqlite3_load_extension(hDB, aosExtensions[i], nullptr,
>>> &pszErrMsg) != SQLITE_OK )
>>> ^
>>> 2 errors generated.
>>> make[2]: ***
>>> [ogr/ogrsf_frmts/sqlite/CMakeFiles/ogr_SQLite.dir/ogrsqlitedatasource.cpp.o]
>>> Error 1
>>> make[1]: *** [ogr/ogrsf_frmts/sqlite/CMakeFiles/ogr_SQLite.dir/all] Error 2
>>> make: *** [all] Error 2
>>> ==========
>>>
>>> So I then build SQLite manually, including the requirements that the
>>> built-in macOS SQLite seems to be missing, and install to ~/build. Ie,
>>>
>>> ./configure SQLITE_ENABLE_RTREE=1 --prefix=/Users/{USERNAME}/build
>>>
>>> Then I attempt to GDAL again as follows:
>>>
>>> cd gdal-{VERSION}
>>> rm -r build
>>> mkdir build
>>> cd build
>>> cmake -DSQLITE3_INCLUDE_DIR=~/build/include
>>> -DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a ..
>>>
>>>
>>> Now cmake fails with:
>>>
>>> -- Configuring incomplete, errors occurred!
>>> See also "...../CMakeOutput.log".
>>> See also "...../CMakeError.log".
>>>
>>> The error log is fairly long, but two errors near the beginning seem to be
>>> perhaps quite significant:
>>>
>>> ld: library not found for -lSystem
>>>
>>> and a bit further on:
>>>
>>> ld: library not found for -lc++
>>>
>>> and then skipping to the end of the error log:
>>>
>>> ==========
>>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19:
>>> error: use of undeclared identifier '_iconv_close'; did you mean
>>> 'iconv_close'?
>>> return ((int*)(&_iconv_close))[argc];
>>> ^~~~~~~~~~~~
>>> iconv_close
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/iconv.h:78:36:
>>> note: 'iconv_close' declared here
>>> extern __LIBICONV_DLL_EXPORTED int iconv_close (iconv_t _cd);
>>> ^
>>> 1 error generated.
>>> make[1]: *** [CMakeFiles/cmTC_825af.dir/CheckSymbolExists.c.o] Error 1
>>> make: *** [cmTC_825af/fast] Error 2
>>>
>>>
>>> File
>>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
>>> /* */
>>> #include <iconv.h>
>>>
>>> int main(int argc, char** argv)
>>> {
>>> (void)argv;
>>> #ifndef _iconv_close
>>> return ((int*)(&_iconv_close))[argc];
>>> #else
>>> (void)argc;
>>> return 0;
>>> #endif
>>> }
>>> ==========
>>>
>>> Now if I try the following:
>>>
>>> export LDFLAGS=-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
>>> export CFLAGS="-isysroot
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
>>> export CCFLAGS="-isysroot
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
>>> export CXXFLAGS="-isysroot
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
>>> export CPPFLAGS="-isysroot
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
>>> cd gdal-{VERSION}
>>> rm -r build
>>> mkdir build
>>> cd build
>>> cmake -DSQLITE3_INCLUDE_DIR=~/build/include
>>> -DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a ..
>>>
>>> Then the -lsystem and -lc++ errors disappear, but the iconv errors are
>>> still there.
>>>
>>> I’m clearly doing something quite wrong, but I’m just a hobbyist and cannot
>>> figure it out any further than this.
>>>
>>> Thanks for bearing with me if you’ve managed to read this far. I’d be
>>> grateful for some assistance to get this to build using cmake.
>>>
>>> Cheers,
>>> Nik.
>>>
>>> _______________________________________________
>>> gdal-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> --
>> http://www.spatialys.com <http://www.spatialys.com/>
>> My software is free, but my time generally not.
>>
>
>
> ========================================================
> NIK SANDS
> Line Tamer | Time Traveller | Space Cadet
>
========================================================
NIK SANDS
Line Tamer | Time Traveller | Space Cadet
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
