[gdal-dev] building on macOS - fatal error: 'direct.h' file not found
Nik Sands
nik at nixanz.com
Sun Jul 3 21:03:10 PDT 2022
Hi John,
Thanks for this information. This was definitely not the case when I first started building iOS apps (quite some time ago), so I’ll have to do some further research to make sure I can incorporate dynamic libraries if/when appropriate.
Cheers,
Nik.
> On 4 Jul 2022, at 1:16 pm, John Daniel <jdaniel at etresoft.com> wrote:
>
> Nik,
> You can definitely use dynamic linking in an iOS app.
>
> I don’t know how you would do that in CMake.
>
> John Daniel
> Etresoft, Inc.
>
>> On Jul 3, 2022, at 9:17 PM, Nik Sands <nik at nixanz.com> 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 <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> 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
>>>> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>>>> 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
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220704/daaa5eaf/attachment-0001.htm>
More information about the gdal-dev
mailing list