auditwheel 5.2.0: Unable to find shared object files when installing wheels repaired with auditwheel==5.2.0
learnforpractice opened this issue · 5 comments
running an executable file that was processed by auditwheel repair --plat manylinux_2_31_x86_64 shows the following error:
error while loading shared libraries: ibssl-578d2f9a.so.1.1: cannot open shared object file: No such file or directory
version 5.1.2 is ok.
do you have a reproducer for this ?
all our tests are passing so it's not easy to tell what went wrong here.
see
https://github.com/learnforpractice/ipyeos-1/actions/runs/3303572530/jobs/5451643526
and here is the workflow file:
https://github.com/learnforpractice/ipyeos-1/blob/main/.github/workflows/build-pyeos-manylinux.yml
change auditwheel==5.2.0 back to auditwheel==5.1.2 in the above file will not have such an issue.
You're most likely hitting NixOS/patchelf#158, most likely fixed by NixOS/patchelf#335
I get the same behavior as auditwheel 5.1.2 (tests failing with loading /usr/lib/x86_64-linux-gnu/libpython3.10.so failed!) when I update patchelf from 0.10 to 0.15.
You can get an up-to-date patchelf with pip install patchelf so in your reproducer:
python3.10 -m pip install scikit-build cython auditwheel patchelf works (well, same failure as 5.1.2)
Thank you, install patchelf do fix this issue.
It's weird with version 5.1.2 I don't need to do this.
About loading so issue, that's out of topics, PYTHON_SHARED_LIB_PATH=${{ env.pythonLocation }}/lib/libpython3.10.so ipyeos fix it.
5.2.0 changed the way multiple replacements are handled to speed-up the process.
It has some impact (as was the case here). Depending on wether or not it has too much impact, we might do a version patch with a minimum patchelf version for this feature to be enabled (but it's unclear if/how the bug mentioned in patchelf only affects multiple calls at once) or just bump the minimum required version of patchelf.