"CheckIncludeFile.c:1:10: fatal error: 'direct.h' file not found" is not
an issue when it happens during the CMake configuration phase, ie when
you run "cmake" (it is not expected during the build phase of course).
The GDAL CMake configuration tries to find which header files are there
or not :
https://github.com/OSGeo/gdal/blob/9aa17692a54a2c6afe2fa9a1cabc3443837f8fca/cmake/helpers/configure.cmake#L38
We do test CMake on MacOS in our continuous integration:
https://github.com/OSGeo/gdal/blob/9aa17692a54a2c6afe2fa9a1cabc3443837f8fca/.github/workflows/cmake_builds.yml#L524
I'm not sure that setting of LDFLAGS, CFLAGS, etc. is necessary.
Even
Le 28/06/2022 à 03:19, Nik Sands a écrit :
Hi GDAL devs,
Since I last built GDAL (2.2.2), cmake has been introduced and it appears as
though it is going to be the only option going forward. So I’m attempting to
use cmake to build GDAL 3.5.0 on macOS 12.4 ('Monterey’). I’ve installed cmake
using the ‘homebrew’ macOS package manager.
However, I’m getting numerous build errors, starting with the following error
when running cmake to build GDAL 3.5.0:
fatal error: 'direct.h' file not found
(a little more context from the error log is included at the end, below)
I’m attempting to build GDAL as follows:
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-3.5.0
mkdir build
cd build
cmake -DPROJ_ROOT=~/build -DSQLITE3_INCLUDE_DIR=~/build/include
-DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a .. -DCMAKE_INSTALL_PREFIX=~/build
-DCMAKE_BUILD_TYPE=Release ..
I’m a hobbyist and not a professional developer, so my understanding of these
things is quite limited. However, my research so far indicates that ‘direct.h’
is a Windows-specific header file and therefore perhaps cmake has not been
configured correctly for macOS in this GDAL distribution?
Is it possible to build GDAL using cmake on macOS? If so, how to I deal with
this error?
I can supply the entire CMakeError.log file if that would help (as an
attachement, or copy/pasted as text in an email).
Cheers,
Nik.
Snippet from CMakeError.log:
------------------------------
Source file was:
int main() { return 0; }
Determining if the include file direct.h exists failed with the following
output:
Change Dir:
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make -f Makefile cmTC_190db/fast &&
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f
CMakeFiles/cmTC_190db.dir/build.make CMakeFiles/cmTC_190db.dir/build
Building C object CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
-std=gnu99 -MD -MT CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o -MF
CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o.d -o
CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o -c
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10:
fatal error: 'direct.h' file not found
#include <direct.h>
^~~~~~~~~~
1 error generated.
make[1]: *** [CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o] Error 1
make: *** [cmTC_190db/fast] Error 2
------------------------------
========================================================
NIK SANDS
Line Tamer | Time Traveller | Space Cadet
_______________________________________________
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.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
