[gdal-dev] Problems compiling in Mac

[Carsten Schultz]

Hallo!

> On 23. Nov 2023, at 18:12, Javier Jimenez Shaw via gdal-dev <gdal-dev at 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.rouault at 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.