Arne Babenhauserheide <arne_bab@web.de> writes:

> Hello Ludo`,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> validating RUNPATH of 6 binaries in "/gnu/store/q9sb0wv41ig429f1m1xspg22xm8pwpwh-gdal-2.2.4/lib"...
>>> /gnu/store/q9sb0wv41ig429f1m1xspg22xm8pwpwh-gdal-2.2.4/lib/python3.7/site-packages/osgeo/_gdal.cpython-37m-x86_64-linux-gnu.so:
>>> error: depends on 'libgdal.so.20', which cannot be found in RUNPATH
>>> ("/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/lib"
>>> "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib"
>>> "/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib"
>>> "/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..")
>>
>> I’m not familiar with Cython so I don’t know how this was handled
>> before.  However, to me, it indicates that the resulting binaries are
>> unlikely to work.
>>
>> Namely, Python would dlopen “_gdal.cython*.so”, and that would fail to
>> find ‘libgdal.so’.

>>
>> Thoughts?
>
> Yes: It does work. But I don’t know why.

This is because the _gdal.cython*.so don't have rpath to the "lib"
directory, where libgdal.so will going.

>
> Cython runs at compile-time to generate c-code that acts as interface
> for Python. Given the paths in here, this needs gdal already installed
> in the runpath where it seems to be missing during validation.
>
> How can we fix that?

I think cython (which compile .py files to .c files) is not here..  It
has python C libraries generated by swig.
>
> Best wishes,
> Arne

In the end the python bindings for gdal can be build seperated (which
handle the missing rpath to libgdal nicely), and I prefer this way: