Hallo! > On 23. Nov 2023, at 18:12, Javier Jimenez Shaw via gdal-dev > <gdal-dev@lists.osgeo.org> wrote: > > My colleague (I have only Linux) will give more info.
I am that colleague. > > On Thu, 23 Nov 2023 at 16:25, Even Rouault <even.roua...@spatialys.com> wrote: > >>> >>> I thought that it was enough disabling GDAL_USE_EXTERNAL_LIBS (we are not >>> enabling explicitly arrow or kml). Am I wrong? >> He might have to remove CMakeCache.txt because it could contain the >> GDAL_USE_LIBKML=ON declaration that was set before turning off >> GDAL_USE_EXTERNAL_LIBS >> He started from an empty directory. >> >> We are using conan, that is python, and setting GDAL_USE_EXTERNAL_LIBS=False >> . This is the result after searching for that string: > and what is the value of GDAL_USE_LIBKML and GDAL_USE_ARROW ? and what is the > exact error message? I have re-tested everything, and at the moment I can only reproduce the libkml problem. It is that GDAL_USE_EXTERNAL_LIBS=OFF is not respected by the configuration for that library. Longer version: We use > GDAL_USE_EXTERNAL_LIBS:BOOL=False with the intention that no external libraries are used unless requested explicitly. This works fine for other libraries. (E.g. "-- ARROW has been found, but is disabled due to GDAL_USE_EXTERNAL_LIBS=OFF. Enable it by setting GDAL_USE_ARROW=ON”. The detection for some of those libraries produced warnings, though, maybe there were actual errors in the past.) However, GDAL_USE_LIBKML seems not to respect that, and it still ends up ON in case that I happen to have it installed. This then also triggers OGR_ENABLE_DRIVER_LIBKML=ON. Now it so happens that compilation then fails because of a version mismatch between the Boost version that the libkml that I have installed via homebrew expects and the Boost that I told GDAL to use, but that’s not the main problem. Even if it would compile, we would not want the result of the GDAL build depend on whether libkml is installed somewhere or not. We can of course work around this by explicitly setting GDAL_USE_LIBKML=OFF. Thanks for your time, Carsten P.S.: Even longer version. To test I did the following. I first ran GDAL’s CMake with the settings that we use (which include GDAL_USE_EXTERNAL_LIBS=False). I then installed gdal via homebrew, removed it again (probably not a necessary step, it occurs to me now), but left all of its dependencies in place. I then ran GDAL’s CMake again, with the same settings and a clean directory. These are the differences: $ rg :BOOL= gdal-clean/build/d185604a596dec60cbd1808d822f70b0e1117b56/CMakeCache.txt > clean-bools $ rg :BOOL= gdal-dirty/build/d185604a596dec60cbd1808d822f70b0e1117b56/CMakeCache.txt > dirty-bools $ diff clean-bools dirty-bools 172a173,175 > GDAL_USE_ARROW:BOOL=OFF > GDAL_USE_ARROWDATASET:BOOL=OFF > GDAL_USE_CFITSIO:BOOL=OFF 176a180 > GDAL_USE_FREEXL:BOOL=OFF 187a192 > GDAL_USE_JSONC:BOOL=OFF 190a196 > GDAL_USE_LERC:BOOL=OFF 191a198 > GDAL_USE_LIBKML:BOOL=ON 194a202,203 > GDAL_USE_NETCDF:BOOL=OFF > GDAL_USE_ODBC:BOOL=OFF 197a207 > GDAL_USE_OPENJPEG:BOOL=False 198a209 > GDAL_USE_PARQUET:BOOL=OFF 202a214 > GDAL_USE_POPPLER:BOOL=OFF 203a216 > GDAL_USE_QHULL:BOOL=OFF 205a219 > GDAL_USE_SPATIALITE:BOOL=OFF 209a224 > GDAL_USE_XERCESC:BOOL=OFF 243a259,260 > OGR_ENABLE_DRIVER_LIBKML:BOOL=ON > OGR_ENABLE_DRIVER_LIBKML_PLUGIN:BOOL=OFF All of the extra FALSE entries are from stuff which has now been detected but ignored as wanted, they are ok. Just LIBKML doesn’t play nicely. My main testing was with 3.6.4, but I also did a quick test with 3.8.0 and I saw the same behaviour. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
