Link to libgdal.so instead of libgdal.so.26

[xianwenchen]

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.

[visr]

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 GDAL_jll package const libgdal = "libgdal.so.26" is changed to const libgdal = "libgdal.so" you are able to override it but otherwise not? If this needs fixing it will likely have to be in https://github.com/JuliaPackaging/BinaryBuilder.jl though. I don't know if there are specific reasons that the ".26" version is chosen.

[xianwenchen]

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.

[visr]

If from https://github.com/JuliaBinaryWrappers/GDAL_jll.jl/releases/tag/GDAL-v3.0.4%2B1 I download, say, GDAL.v3.0.4.x86_64-linux-gnu-cxx11.tar.gz, I see these 3 files, of which two are symlinks.

libgdal.so -> libgdal.so.26.0.4
libgdal.so.26 -> libgdal.so.26.0.4
libgdal.so.26.0.4

This is ok for you right? So it's only about changing const libgdal = "libgdal.so.26" to const libgdal = "libgdal.so" in the generated wrapper code?

@giordano is there a reason the _jll code refers to the libgdal.so.26 symlink and not the libgdal.so one?

[giordano]

To be honest, I don't remember the criterion with which the name is chosen.

[visr]

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 soname, or defaults to the basename if that doesn't work: https://github.com/JuliaPackaging/BinaryBuilder.jl/blob/1fad501c2dcf0f65051b1432bdacb37ba497377a/src/AutoBuild.jl#L725-L728

[giordano]

Right, it has to be the soname!

[visr]

Out of interest, why does it have to be the soname? ccall also works on just libgdal

@xianwenchen, I think there is not much we can do about this here. You could modify your local GDAL_jll to update the const libgdal = line, try using a system GDAL 3.0 instead, or help updating the Yggdrasil GDAL recipe to GDAL 3.1.

[giordano]

ccall also works on just libgdal

What do you mean? 🤔

[visr]

Right now we effectively use ccall((function_name, "libgdal.so.26"), ...) in GDAL.jl, since const libgdal = "libgdal.so.26" in the JLL package. But ccall((function_name, "libgdal"), ...) also works, right? That is what I used to do before BinaryBuilder.

[xianwenchen]

Out of curiosity, can I use ccall to call my system's libgdal.so.26 directly?

[visr]

Yeah that should be possible. You may need to have to disable the _jll loading in GDAL.jl, and then you can set const libgdal yourself to anything you like. "libgdal" should make it pick up the system version then, if that is on the path.

[lix19937]

sudo apt-get install libgdal-dev