Update to GDAL 3.10.0, and add libgdal-avif and libgdal-heif

[rouault]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[rouault]

@conda-forge-admin, please rerender

[rouault]

@conda-forge-admin, please rerender

[rouault]

@conda-forge-admin, please rerender

[rouault]

@conda-forge-admin, please rerender

[rouault]

pull request updated to final 3.10.0 release

[akrherz]

🥳 Thank you!

[akrherz]

Oh, we'd likely want to include a 3.9.x migration branch. I can push that once the bot reports back...

[akrherz]

I suspect this will be somewhat painful as the libhdf5 migration is currently stuck on conda-forge/kealib-feedstock/pull/65, so a migration for gdal 3.10 may be troubles / stuck as well given the complex dependencies!

[akrherz]

On windows, we don't have the icu + libxml2 multiple builds issue, but we still have a problem there

 validation results:
 {
   "win-64\\libgdal-avif-3.10.0-h6a3d85c_0.conda": false,
   "win-64\\libgdal-heif-3.10.0-hd0e23a6_0.conda": false,
 }

For the life of me, I can't resolve in the logs what the failure is. Is it a mixed case issue with the test looking for gdalplugins/gdal_avif.dll and the file is named gdalplugins/gdal_AVIF.dll ? for example

[akrherz]

For non-windows, I wonder if we should just hack in a icu requirement, since libgdal-core requires xerces-c which requires icu anyway on non-windows. I'll push two commits here and see what happens...

[rouault]

Is it a mixed case issue with the test looking for gdalplugins/gdal_avif.dll and the file is named gdalplugins/gdal_AVIF.dll ? for example

I don't think so, since the test does check for if not exist %LIBRARY_LIB%\gdalplugins\%GDAL_PLUGIN_TYPE%_%GDAL_PLUGIN_NAME%.dll exit 1 and GDAL_PLUGIN_NAME is upper case. Any way that test succeeds, since one can see in the output log the output of the next line which is gdalinfo --format %GDAL_PLUGIN_NAME% . So the failure is a mystery. I'd note that in my earlier attempts on RC builds, all builds succeeded. So this must be something else, not linked to the content of the recipe which hasn't changed.

[akrherz]

@conda-forge-admin please rerender

[akrherz]

I don't think so

Yeah, you are right. Lets see if we can fix non-win first with my hack.

[akrherz]

Well, my icu idea went up in flames already. The most recent main branch success was with libxml2=2.12.7, which was prior to the no/yes icu build variants shown up. So alas...

[four43]

I'm crossing my fingers over here as I see these CI runs spinning. We're cheering you on @akrherz - you're fighting the good fight!

[akrherz]

Well, at least the linux build is failing in the same manner as windows, backwards progress! Boggling...

[akrherz]

oOo, we are hitting this due to attempting to upload new packages not previously associated with this repo....

[rouault]

Well, at least the linux build is failing in the same manner as windows, backwards progress! Boggling...

I've no idea why we have an issue specifically on the new HEIF and AVIF sub-packages, but they are far from being essential. I'd suggest we remove them for now, if that's enough to get an initial 3.10.0 green build...

[akrherz]

So my icu dependency hack seems to be "working". A kind ping to @isuruf for comments on doing this. I am attempting to make the dep solver pick the right libxml2 build with icu support, which is needed by xerces-c anyway.

Would be nice to have somebody else sign off on this as being OK :)

[akrherz]

My hope is that this turns green now and will take it, if so! Will followup with creating a v3.9.x branch and PR the same icu hack there as well. We will still have the issue of thinking about when to try a gdal 3.10 migration, we may have to wait on it yet :(

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[rouault]

The osx arm64 build, on the build matching this merged PR, failed ,presumably due to some transient error (https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1079258&view=logs&j=d6b58996-039f-5e48-56bf-c3a016e5cd7f&t=dd6a23d9-2356-5264-64bf-579875a5d8d6) . Could someone restart it ? (and thanks @akrherz for the workaround!)

[akrherz]

Thank you, restarted that job.

[rouault]

Still failing with

+ cmake '-U*LATER_PLUGIN' -DBUILD_PYTHON_BINDINGS:BOOL=OFF -DCMAKE_AR=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ar -DCMAKE_CXX_COMPILER_AR=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ar -DCMAKE_C_COMPILER_AR=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ar -DCMAKE_RANLIB=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ranlib -DCMAKE_CXX_COMPILER_RANLIB=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ranlib -DCMAKE_C_COMPILER_RANLIB=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ranlib -DCMAKE_LINKER=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-ld -DCMAKE_STRIP=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-strip -DCMAKE_INSTALL_NAME_TOOL=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-install_name_tool -DCMAKE_LIBTOOL=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin/arm64-apple-darwin20.0.0-libtool -DCMAKE_OSX_DEPLOYMENT_TARGET=11.0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_OSX_SYSROOT=/Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_FIND_APPBUNDLE=LAST -DCMAKE_INSTALL_PREFIX=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh -DCMAKE_INSTALL_LIBDIR=lib '-DCMAKE_PROGRAM_PATH=/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_build_env/bin;/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/bin' -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_SYSTEM_PROCESSOR=arm64 -DCMAKE_SYSTEM_VERSION=20.0.0 -DCMAKE_OSX_DEPLOYMENT_TARGET=11.0 -DGDAL_USE_PARQUET=ON -DGDAL_USE_ARROW=ON -DGDAL_USE_ARROWDATASET=ON -DOGR_ENABLE_DRIVER_ARROW=ON -DOGR_ENABLE_DRIVER_ARROW_PLUGIN=ON -DOGR_ENABLE_DRIVER_PARQUET=ON -DOGR_ENABLE_DRIVER_PARQUET_PLUGIN=ON /Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/work
dyld[9215]: Library not loaded: @rpath/libzstd.1.dylib
  Referenced from: <A0C6CBC7-8F86-39B9-8CDA-35B5CC4AAEA2> /Users/runner/miniforge3/pkgs/cmake-3.30.5-h7243fc2_0/bin/cmake
  Reason: tried: '/Users/runner/miniforge3/pkgs/cmake-3.30.5-h7243fc2_0/bin/../lib/libzstd.1.dylib' (no such file), '/Users/runner/miniforge3/pkgs/cmake-3.30.5-h7243fc2_0/bin/../lib/libzstd.1.dylib' (no such file), '/usr/local/lib/libzstd.1.dylib' (no such file), '/usr/lib/libzstd.1.dylib' (no such file, not in dyld cache)
/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/work/build_plugin.sh: line 37:  9215 Abort trap: 6           cmake "-U*LATER_PLUGIN" -DBUILD_PYTHON_BINDINGS:BOOL=OFF ${CMAKE_ARGS} ${SRC_DIR}
Traceback (most recent call last):
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/build.py", line 1785, in bundle_conda
    utils.check_call_env(
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/utils.py", line 404, in check_call_env
    return _func_defaulting_env_to_os_environ("call", *popenargs, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/utils.py", line 380, in _func_defaulting_env_to_os_environ
    raise subprocess.CalledProcessError(proc.returncode, _args)
subprocess.CalledProcessError: Command '['/bin/bash', '-e', '/Users/runner/miniforge3/conda-bld/libgdal-core_1731497742493/work/build_plugin.sh']' returned non-zero exit status 134.

I suspect this is some cross compilation issue. Perhaps restart again.. ? (In GDAL master on github CI, MacOS ARM64 builds work fine: https://github.com/OSGeo/gdal/actions/runs/11816321717/job/32919368044)

[akrherz]

Perhaps restart again..

Restarting a second time appears to have been a charm, also build 1 appeared to succeed as well. Thank you @rouault for all the efforts with this repo!