[gdal-dev] GDAL 3.10.2 release candidate available

[Roger Bivand]

Even,

On Tue, 11 Feb 2025, Even Rouault wrote:

> Roger,
>
> curl > = 7.68 was made a requirement for GDAL 3.9 per 
> https://gdal.org/en/stable/development/rfc/rfc98_build_requirements_gdal_3_9.html 
> a bit more than one year ago.
>
> You can try to downgrade the minimum version by patching 
> https://github.com/OSGeo/gdal/blob/51ee2933c08896648613488926bff36939a66be7/cmake/helpers/CheckDependentLibraries.cmake#L29 
> and see if GDAL still builds with it. It might. This is just untested 
> territory. If that builds, that should be fine. If that doesn't, minor 
> patches might be needed.
>

We are planning to use 3.8.5, the minor patches would have been of the 
larger kind of minor.

> Has it considered that R on Mac ships with a custom libcurl build that is up 
> to date ? After all, if you ship an up-to-date GDAL why not shipping an 
> up-to-date libcurl as well?

The R static build train provides libraries for R itself and all the 
packages for both architectures, based as far as possible on Xcode plus a 
Fortran compiler. So changing one central component isn't so attractive, 
as it may impact other libraries. For the Windows static binaries, MXE is 
used for cross-compilation, so more of the context is under our control.

Roger


>
> Even
>
>
> Le 11/02/2025 à 21:00, Roger Bivand via gdal-dev a écrit :
>>  R-spatial for macOS static builds have run into a serious roadblock at
>>  3.10.1, so maybe an early 3.10.2 could assist us.
>>
>>  Until recently, static macOS builds of GDAL were using 3.5.3. Simon
>>  Urbanek
>>  (https://github.com/R-macos/recipes)
>>  has just converted the recipe for GDAL to cmake, and things were looking
>>  positive for 3.10.1, until we realised that:
>>
>>  -- Found CURL:
>>  /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libcurl.tbd
>>  (found version "7.64.1")
>>  [...]
>>   checking whether CURLOPT_USERNAME is defined... yes
>>   checking whether CURLOPT_PASSWORD is defined... yes
>>   checking whether CURLOPT_KEYPASSWD is defined... yes
>>   checking whether CURLINFO_RESPONSE_CODE is defined... yes
>>   checking whether CURLOPT_BUFFERSIZE is defined... yes
>>   checking whether CURLOPT_TCP_KEEPALIVE is defined... yes
>>   checking whether libcurl is version 7.66 or later?... no
>>
>>  so CURL is available but the MacOSX11.3.sdk version is insufficient -
>>  macOS 11.3 is the mandated build platform for R and R packages to
>>  accommodate most Darwin systems from older to newest.
>>
>>  Building GDAL on the cmake step says:
>>
>>  CURL component has been detected, but is disabled with GDAL_USE_CURL=OFF
>>
>>  during the building of GDAL itself, leading to errors in downstream R
>>  software:
>>
>>  GDAL/OGR not compiled with libcurl support, remote requests not supported.
>>
>>  in sf and terra if opening resources via URL, and in potentially all the
>>  1000+ packages using sf and terra. So unless this can be resolved, we'll
>>  probably have to go back to the last GDAL version not requiring 
>> > = 7.66 or whatever the threshold is and when it was changed.
>>
>>  On the macOS side, it isn't practicable to upgrade the system library for
>>  distribution to many users.
>>
>>  Is it possible to (optionally) specify a minimum CURL version of 7.64 say
>>  when calling cmake in GDAL 3.10? If there is no such possibility now,
>>  could it be added to 3.10.2 (RC2)? Where should I look to try to add a
>>  prototype change?
>>
>>  I didn't see a mention of the tightening of the CURL version requirement
>>  in the NEWS entries, but probably I'm looking in the wrong place.
>>
>>  Best wishes,
>>
>>  Roger
>> 
>

-- 
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: Roger.Bivand at nhh.no