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 <even.roua...@spatialys.com> wrote: > > Nik, > > regarding the build isssue with Mac system sqlite3, I've filed this as > 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 >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > ======================================================== NIK SANDS Line Tamer | Time Traveller | Space Cadet
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev