Closed rayl-bln closed 1 month ago
Sounds like this should be reported to dh-virtualenv, not here. If the lib is there and it's found at import, something is wrong is dh-virtualenv's shlib search.
If it helps, this wheel is built with the now-standard auditwheel/repairwheel workflow used by many wheels, manylinux, cibuildwheel, etc.
thanks, i've opened https://github.com/spotify/dh-virtualenv/issues/365
i do wonder if the lib would always be found at import.
a simple 'ldd' on the libzmq shared object can't find libsodium either.
(.venv) ubuntu@ce5ac35e10ed:/opt/src$ ldd .venv/lib/python3.12/site-packages/pyzmq.libs/libzmq-4192fc97.so.5.2.5
libsodium-37cdab92.so.26.1.0 => not found
this is the only out of 316 deps across 261 shared objects in my virtualenv that does not resolve.
find .venv/ -name \*.so -o -name \*.so.\* | while read f; do echo "============ $f"; ldd $f; done
note that this shared object DOES find the libsodium dep
(.venv) ubuntu@ce5ac35e10ed:/opt/src$ ldd .venv/lib/python3.12/site-packages/zmq/backend/cython/_zmq.cpython-312-x86_64-linux-gnu.so
libzmq-4192fc97.so.5.2.5 => /opt/src/.venv/lib/python3.12/site-packages/zmq/backend/cython/../../../pyzmq.libs/libzmq-4192fc97.so.5.2.5 (0x00007f1498542000)
libsodium-37cdab92.so.26.1.0 => /opt/src/.venv/lib/python3.12/site-packages/zmq/backend/cython/../../../pyzmq.libs/libsodium-37cdab92.so.26.1.0 (0x00007f14981fc000)
it been years since i last looked at this stuff, but IIRC this might have something to do with RPATH?
(.venv) ubuntu@ce5ac35e10ed:/opt/src$ objdump -p .venv/lib/python3.12/site-packages/pyzmq.libs/libzmq-4192fc97.so.5.2.5 | grep RPATH
(.venv) ubuntu@ce5ac35e10ed:/opt/src$ objdump -p .venv/lib/python3.12/site-packages/zmq/backend/cython/_zmq.cpython-312-x86_64-linux-gnu.so | grep RPATH
RPATH $ORIGIN/../../../pyzmq.libs
could it be possible that the libzmq object needs that same RPATH set during wheel build, so that it can also find the libsodium dep?
Can you import zmq
in the env? If not, that's definitely a pyzmq problem! If it works, the detection tool is not accurately detecting the how libraries get loaded.
It's worth noting that both libzmq and libsodium are exclusively loaded by that _zmq
. So maybe loading libzmq directly on its own wouldn't work, but that doesn't matter in practice because it never happens, except by this tool which makes imprecise assumptions. If that's the case, perhaps the package to report the issue to is auditwheel, because it may only be performing the rpath patch on Extension modules, but not on intermediate libs like libzmq in pyzmq, which have transitive dependencies (_zmq -> libzmq -> libsodium). And maybe there's a flag pyzmq should be passing to auditwheel.
import zmq
definitely works, so i'll chase the various tools folks. thanks for reviewing!
I think this is already reported in auditwheel as https://github.com/pypa/auditwheel/issues/451 . Apparently audithweel fixes RPATH when it's defined, but doesn't add it. Adding (unnecessary, but not wrong) RPATH when we build libzmq seems to solve the problem: #2014. When it finishes, can you test with the appropriate wheel from this run? I think it will work.
Looks good! built the deb with the new wheel and did a quick sanity check, seems to work fine. thanks for the speedy fix :-)
Thanks for testing!
This is a pyzmq bug
What pyzmq version?
26.1.0
What libzmq version?
4.3.5
Python version (and how it was installed)
Python 3.12.3, ubuntu 24.04
OS
ubuntu 24.04
What happened?
When I try to package it using dh-virtualenv and dh-poetry, I get a failure on the "dh_shlibdeps" step.
the library seems to be properly included in
pyzmq-26.1.0-cp312-cp312-manylinux_2_28_x86_64.whl
Code to reproduce bug
No response
Traceback, if applicable
More info
No response