JuliaPackaging / Yggdrasil

Collection of builder repositories for BinaryBuilder.jl
https://binarybuilder.org
Other
304 stars 538 forks source link

[GDAL] Fix Windows build issues #8781

Closed visr closed 2 months ago

visr commented 4 months ago

Recently GDAL was bumped to 3.9.0 in #8512. This release seems to work fine on all platforms and is released as https://github.com/JuliaBinaryWrappers/GDAL_jll.jl/releases/tag/GDAL-v301.900.0%2B0.

In #8749 more features/dependencies were added to the 3.9.0 build, but unfortunately this build is broken on Windows for currently unknown reasons; https://github.com/JuliaPackaging/Yggdrasil/pull/8746#issuecomment-2131004869. This is separate from the fix applies in #8755.

In https://github.com/JuliaRegistries/General/pull/107721 the broken https://github.com/JuliaBinaryWrappers/GDAL_jll.jl/releases/tag/GDAL-v301.901.0%2B0 was yanked, so we can look into this issue.

Also if #8780 is already fixed we should bump the PROJ version, and ideally we also fix https://github.com/JuliaGeo/GDAL.jl/issues/171#issuecomment-2080161907.

visr commented 3 months ago

@eschnett should we just revert #8749 for now? In #8965 @jeremiahpslewis updated to 3.9.1 and now GDAL is broken again on Windows. Probably we should've reverted directly such that the build script wasn't in a broken state.

julia> using GDAL_jll
ERROR: InitError: could not load library "C:\Users\visser_mn\.julia\artifacts\9db36ce542776801f81c6432d08864ea4abfc279\bin\libgdal-35.dll"
The specified module could not be found.
Stacktrace:
  [1] dlopen(s::String, flags::UInt32; throw_error::Bool)
    @ Base.Libc.Libdl .\libdl.jl:120
visr commented 3 months ago

I don't know how to find the cause for this, any ideas? I assume the issue is with one of the added dependencies, so I tried https://github.com/giordano/DependencyWalker.jl but it cannot find any of them. Nothing really stood out to me in the logs. Though I don't understand why the Windows build passed the audits if it doesn't load.

eschnett commented 3 months ago

It might be that the version of the dependencies loaded during the audit is different from the version of the dependencies loaded at run time. If the versions are marked as compatible for Julia (e.g. they differ only in their minor version number), but are actually incompatible for some reason (e.g. the shared libraries don't match, or have different names), then you would see this kind of error.

eschnett commented 3 months ago

I think the path forward would be first to decide how to handle this. If I recall there are two options:

After that decision we would build new packages (with respective new version numbers), and then probably have the broken packages removed from the registry, or possible change the dependencies declarations in the registry (I'm not very familiar with this process).

visr commented 3 months ago

I think the GDAL name is already ok with the soversion in it. For PROJ we can use this, assuming it doesn't change: https://github.com/OSGeo/PROJ/pull/4167