Update to GDAL 3.7.x

[CloudNiner]

Once #99 is merged, so that brew install gdal on MacOS works out of the box again for these bindings and geotrellis.

[pomadchin]

Also according to https://mvnrepository.com/artifact/org.gdal/gdal we'd need to do a fresh release every GDAL minor release.

[jamesmcclain]

Once again advertising #91 as a solution to this (would leave Windows behind, though).

[jpolchlo]

Hello, folks! This issue needs to be reconsidered. GDAL is now up to version 3.7, and I'm finding it difficult to even find a way to install GDAL 3.1.2 from within my package manager. I'd love to get a rough idea of how to adjust the dependency version so that I can get into this update. At least to provide a provisional branch to get something working with a contemporary GDAL version. Any thoughts?

[pomadchin]

Eh we really need to make a fresh linux / mac release ): Most likely no code change is required, it's all the CI / build complexities.

The workaround for now is the PR review comment, smylinking: install any GDAL version and symlink the .so lib to the expected, i.e.

ln -s /usr/local/lib/libgdal.28.dylib /usr/local/lib/libgdal.27.dylib

+ hope that it's binary compatible. At some point (since GDAL 3.0) GDAL decided to change the .so binary we link with every release.

[pomadchin]

That's the last time we've doen the 2.x => 3.x update c2904a5 and it's been not that bad (check the Docker files and the build itself)

Mostly it's been just env build updates.

[jpolchlo]

Indeed, the build is being a bit of a pain. Local builds needed some updates (e.g., pthread_yield ➔ sched_yield), and now the tests are failing. Docker containers are also being persnickety.

It may be a worthwhile thing to adjust the release versions here to somehow match the GDAL version. For instance, gdal-warp-bindings-3.x.y is the yth release of the library for GDAL 3.x. This would sure make it easier to provide an immediately-useful version for whichever libgdal.so version is in the user's environment.

[pomadchin]

A nice idea, I like it!

I'm doing smth similar in the PDAL repo; {major}.{minor} - to match PDAL; .{patch} is a lib update within the corresponding PDAL version.

[jamesmcclain]

Eh we really need to make a fresh linux / mac release ): Most likely no code change is required, it's all the CI / build complexities.

The workaround for now is the PR review comment, smylinking: install any GDAL version and symlink the .so lib to the expected, i.e.

ln -s /usr/local/lib/libgdal.28.dylib /usr/local/lib/libgdal.27.dylib

• hope that it's binary compatible. At some point (since GDAL 3.0) GDAL decided to change the .so binary we link with every release.

I think we want to be careful about using symlinks to resolve dependencies on different minor numbers. It might work temporarily or even permanently in this or that circumstance, but is quite dangerous!