-
Notifications
You must be signed in to change notification settings - Fork 13
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
Link to libgdal.so instead of libgdal.so.26 #93
Comments
Are you referring to this line? https://github.com/JuliaBinaryWrappers/GDAL_jll.jl/blob/a242496e63a7656ee175d31d20bf025165567e07/src/wrappers/aarch64-linux-gnu-cxx11.jl#L461 In https://github.com/JuliaPackaging/Yggdrasil/tree/master/G/GDAL there is nothing specifying this, so this is how https://github.com/JuliaPackaging/BinaryBuilder.jl does it by default. I understand you issue regarding the symlinks, but don't understand how this affects the option to override the BinaryBuilder provided binary. So if in the |
Thank you. Yeah. It seems that it was that line that was causing the issue: https://github.com/JuliaBinaryWrappers/GDAL_jll.jl/blob/a242496e63a7656ee175d31d20bf025165567e07/src/wrappers/aarch64-linux-gnu-cxx11.jl#L461 .26 was chosen by the developers of the gdal library version 3.0.x. They switched to .27 for gdal version 3.1.x. I however consider this a minor bug of, now seems, BinaryBuilder.jl. I think in this way. Right now GDAL_jll.jl packages gdal version 3.0.4, which has libgdal.so.26. The gdal version 3.1.x (3.1.0, 3.1.1, 3.1.2) has libgdal.so.27. For computers that have gdal version 3.1.x or newer, Julia would not find libgdal.so.26. However, it is a common practice for Linux distributions to create a softlink, libgdal.so, to the libgdal.so.xx. And all libraries that depend on libgad.so.xx should link to libgdal.so. Because when gdal is upgraded, the xx number changes (as from 26 to 27). If a library was linked to libgdal.so.26, the library would stop functioning once the gdal library becomes libgdal.so.27. However, if the library was linked to libgdal.so, the library would be okay when the gdal library becomes libgdal.so.27, because Linux distributions almost always create a new softlink libgdal.so that links to the newer version of libgdal.so.xx. |
If from https://github.com/JuliaBinaryWrappers/GDAL_jll.jl/releases/tag/GDAL-v3.0.4%2B1 I download, say,
This is ok for you right? So it's only about changing @giordano is there a reason the _jll code refers to the |
To be honest, I don't remember the criterion with which the name is chosen. |
Ok, I'm not sure either. It seems to be written by this code: https://github.com/JuliaPackaging/BinaryBuilder.jl/blob/1fad501c2dcf0f65051b1432bdacb37ba497377a/src/AutoBuild.jl#L1065 So it is set to the |
Right, it has to be the soname! |
Out of interest, why does it have to be the soname? @xianwenchen, I think there is not much we can do about this here. You could modify your local |
What do you mean? 🤔 |
Right now we effectively use |
Out of curiosity, can I use |
Yeah that should be possible. You may need to have to disable the _jll loading in GDAL.jl, and then you can set |
It would be more generic, if one links to libgdal.so, instead of libgdal.so.26.
libgdal.so.26, as far as I understand, is for gdal version 3.0.x.
If one installs gdal 3.1.x on the system and override GDAL.jl's asset with the system gdal, one gets a problem. Because gdal 3.1.x's libgdal.so is called libgdal.so.27.
Most of the systems create a soft link of libgdal.so.xx to libgdal.so. All other software on the system would link to libgdal.so. This is to avoid the problem that, for example, a new surfix, such as 27 in libgdal.so.27, would break installed software that were, for example, built against libgdal.so.26.
Does my explanation of the issue understandable? Please let me know if I shall try to explain the issue in a different way.
The text was updated successfully, but these errors were encountered: