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

PROJ: New version 9.4.0 #8746

Merged
merged 3 commits into from
May 23, 2024
Merged

Conversation

eschnett
Copy link
Contributor

No description provided.

@ararslan
Copy link
Member

Looks like you might need to update the preferred_gcc_version?

@giordano giordano merged commit b9a9c21 into JuliaPackaging:master May 23, 2024
32 checks passed
@eschnett eschnett deleted the eschnett/PROJ-9.4.0 branch May 23, 2024 20:29
@visr
Copy link
Contributor

visr commented May 24, 2024

Hmm since this changes the DLL name from libproj_9_3.dll to libproj_9_4.dll it is breaking on Windows. It needed the version_offset major version to be bumped like in #7366. We should probably write this in a comment next to the version numbers.

Now that it is out, I guess General needs to be updated to block PROJ_jll 901.400? Or better to just yank it?

@eschnett
Copy link
Contributor Author

Is it actually incompatible? Would changing the library name on Windows to libproj_9_3.dll be another option?

@visr
Copy link
Contributor

visr commented May 24, 2024

I think it is only the library name on Windows that is the issue I think. The PROJ_SOVERSION is the same so the ABI should otherwise be the same.

@eschnett
Copy link
Contributor Author

That's also how the release notes read. Should we then rename the Windows libraries (and add respective comments) instead of blocking or yanking the package?

@visr
Copy link
Contributor

visr commented May 25, 2024

I'd be fine with that if others agree. It seems like the smoothest upgrade path. I tried locally renaming the DLL in the artifact, and dev PROJ_jll with the same renames. That didn't work yet however, it is not clear why:

julia> using GDAL_jll
ERROR: InitError: could not load library "C:\Users\visser_mn\.julia\artifacts\415bbbe8ca2ee27f90b17984069673e280f25d0d\bin\libgdal-35.dll"
The specified module could not be found.

Note that GDAL_jll has a PROJ_jll dependency, but also via libgeotiff_jll. It is libgeotiff_jll that gives the errors: yeesian/ArchGDAL.jl#427

Of course it could be confusing that PROJ 9.4 has a libproj_9_3.dll. Going forward I'd rather not have the minor version in the name. As far as I can see this is not configurable, but we could ask upstream or patch ourselves:

https://github.com/OSGeo/PROJ/blob/9.4.0/cmake/ProjVersion.cmake#L40-L46
https://github.com/OSGeo/PROJ/blob/9.4.0/cmake/ProjUtilities.cmake#L37-L63
OSGeo/PROJ#3066

@visr
Copy link
Contributor

visr commented May 25, 2024

Actually the libgdal-35.dll seems to be a separate issue affecting the new GDAL_jll versions, because forcing PROJ_jll@901.300 does not resolve that. Users need to downgrade both; add PROJ_jll@901.300 GDAL_jll@301.800.500.

@visr
Copy link
Contributor

visr commented May 27, 2024

I propose we yank these two broken/breaking releases; JuliaRegistries/General#107721

Regarding the libproj DLL name, I also created an upstream issue: OSGeo/PROJ#4151

@joa-quim
Copy link
Contributor

Is it actually incompatible? Would changing the library name on Windows to libproj_9_3.dll be another option?

Unfortunately that does not work on Windows because the dll name in embedded in the dll itself.

@visr
Copy link
Contributor

visr commented May 27, 2024

Thanks @joa-quim. Let's move discussion to #8780.

amontoison pushed a commit that referenced this pull request Jun 22, 2024
* PROJ: New version 9.4.0

* PROJ: Use newer GCC version

* PROJ: Correct case of cmake variable
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants