Description
Hi and thanks for your effort with this project.
I am one of the maintainers of NetworKit, which uses cibuildwheel to build Python wheels. For the current release we got issue reports for the Linux package. Specifically it does not find the underlying shared library (built + included in the wheel).
>>> import networkit as nk
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/brandtfa/miniforge3/envs/py311/lib/python3.11/site-packages/networkit/__init__.py", line 57, in <module>
from . import graph
ImportError: libnetworkit.so: cannot open shared object file: No such file or directory
I did notice when looking into the RPATHs and settings of our current release 11.1 using the current version of auditwheel gets the following:
readelf -d graph.cpython-313-x86_64-linux-gnu.so
Dynamic section at offset 0xd0000 contains 31 entries:
Tag Type Name/Value
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../networkit.libs]
...
In the previous release (March 2024) the entries look like this:
readelf -d graph.cpython-312-x86_64-linux-gnu.so
Dynamic section at offset 0xc4000 contains 31 entries:
Tag Type Name/Value
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/..:$ORIGIN/../networkit.libs]
...
In the main-folder is a shared library called libnetworkit.so, which is needed by all sub-libraries in a subfolder (like the one shown above). Since the original rpath entry $ORIGIN/... (set with CMAKE in the build process) is still present if I manually create the wheel and do not apply auditwheel, it seems that auditwheel exchanges the RPATH. Either replacing the RPATH again or moving the library fixes the problem.
Expected behavior / Question
Is there a reason for auditwheel for removing the RPATH entry and not moving the internal library?
Otherwise I would suggest not change the original RPATH (append instead of remove), move also libraries present in the previous RPATH-path to the .libs subfolder or maybe give a warning.