Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to GDAL 3.7.x #100

Closed
CloudNiner opened this issue Nov 12, 2020 · 8 comments · Fixed by #120
Closed

Update to GDAL 3.7.x #100

CloudNiner opened this issue Nov 12, 2020 · 8 comments · Fixed by #120
Labels
build enhancement New feature or request

Comments

@CloudNiner
Copy link
Contributor

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

@pomadchin
Copy link
Member

pomadchin commented Nov 12, 2020

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

@jamesmcclain
Copy link
Member

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

@jpolchlo
Copy link

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 pomadchin changed the title Update to GDAL 3.4 Update to GDAL 3.7.x Oct 27, 2023
@pomadchin
Copy link
Member

pomadchin commented Oct 27, 2023

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
Copy link
Member

pomadchin commented Oct 27, 2023

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.

@pomadchin pomadchin added enhancement New feature or request build labels Oct 27, 2023
@jpolchlo
Copy link

Indeed, the build is being a bit of a pain. Local builds needed some updates (e.g., pthread_yieldsched_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
Copy link
Member

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
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants