ImportError: a library correctly found and included by auditwheel is not found on package use.

[brenthuisman]

I'm building a wheel for the Arbor Python package, which is a C++ codebase that depends on libxml2. I'm running into the problem that despite the build succeeding, auditwheel correctly finding the libxml*.so* and including it, the execution of our tests fails with ImportError: libxml2-3998bec4.so.2.9.1: cannot open shared object file: No such file or directory.

The workflow uses the cibuildwheel action, but I can reproduce the exact same error with local builds using the pypa/manylinux2014_x86_64 image. See here the output of the workflow at a relevant point: https://github.com/arbor-sim/arbor/runs/4618790432?check_suite_focus=true#step:3:394

auditwheel show on a locally produced wheel shows libxml2-3998bec4.so.2.9.1 being included:

arbor-0.5.3.dev0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
is consistent with the following platform tag:
"manylinux_2_17_x86_64".

The wheel references external versioned symbols in these
system-provided shared libraries: libgcc_s.so.1 with versions
{'GCC_3.4', 'GCC_3.0'}, libc.so.6 with versions {'GLIBC_2.7',
'GLIBC_2.16', 'GLIBC_2.15', 'GLIBC_2.3', 'GLIBC_2.4', 'GLIBC_2.2.5',
'GLIBC_2.3.4', 'GLIBC_2.17', 'GLIBC_2.3.2', 'GLIBC_2.14'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libstdc++.so.6 with versions
{'GLIBCXX_3.4.14', 'CXXABI_1.3.1', 'CXXABI_1.3.3', 'GLIBCXX_3.4.15',
'GLIBCXX_3.4', 'CXXABI_1.3.2', 'GLIBCXX_3.4.18', 'CXXABI_1.3',
'GLIBCXX_3.4.11', 'CXXABI_1.3.5', 'CXXABI_1.3.7', 'GLIBCXX_3.4.19',
'GLIBCXX_3.4.9'}, libdl.so.2 with versions {'GLIBC_2.2.5'},
libpthread.so.0 with versions {'GLIBC_2.3.3', 'GLIBC_2.2.5',
'GLIBC_2.3.2'}, libxml2-3998bec4.so.2.9.1 with versions
{'LIBXML2_2.4.30', 'LIBXML2_2.9.1', 'LIBXML2_2.6.0'}, libz.so.1 with
versions {'ZLIB_1.2.3.3', 'ZLIB_1.2.2.3'}, liblzma-07b5b5c8.so.5.2.2
with versions {'XZ_5.0'}

This constrains the platform tag to "manylinux_2_17_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

Not sure what might be the problem here, or what to do to solve it. Any help is appreciated!

[mayeut]

Would you be by any chance in the same situation as #257 ?

[brenthuisman]

Looks like it!

readelf -d _arbor.cpython-38-x86_64-linux-gnu.so 

Dynamic section at offset 0x595000 contains 32 entries:
  Tag        Type                         Name/Value
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../../../../../../arbor.libs]
[...]

Unfortunately there seems to be no workaround (or fix, since the bug is still open), right? Is there anything you can suggest I can try?

[brenthuisman]

Wrote a small script that patches the rpaths in our wheels post auditwheel. In case you're interested, it's easily adapted for your situation: https://github.com/arbor-sim/arbor/blob/3dc2f266ecb09e535ab35d878fd3a8375e7d2fa8/scripts/patchwheel.py