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]> 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
>> [email protected]
>> 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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
