However, what happens is the shared libraries are all linked twice. The first time it is linked to libraries in the build tree (and do not have links to the old . They are then relinked, I assume as part of installing the files for packaging. At that stage, libhpdiscovery.so* will not be found in debian/tmp/usr/lib/x86_64-linux-gnu, and it picks it up from the local system, if installed, or fails, if not.
If the build picks it up to the local system, and the one in the local system is linked to libnetsnmp.so.30, then this dependency propagates through the other libraries, resulting in libraries that cannot be loaded at all.
I eventually got the build to work by removing all old copies of libhpdiscovery.so* from the system library directories, manually copying libhpdiscovery.so* from the build tree to the system library directories, then freshly extracting the source and rebuilding.
I built using debuild on a live system.I suspect reproducing will not be straight-forward as it requires a system that still has the version of hplip from buster, but has otherwise been upgraded to bullseye. I cannot spare the time right now to set up a test environment and make the attempt to reproduce this, so perhaps this should be closed and left as a record for anybody who encounters the problem later.
On 7/11/21 11:30 am, Thorsten Alteholz wrote:
Control: tag -1 moreinfo Hi Troy,thanks for your bugreport. Unfortunately I have problems understanding what is going on.How can HPLIP link to a missing libhpdiscovery.so.I assume you are building the package in a minimal chroot. How can there be an old version of libhpdiscovery.so available?Can you please be a bit more verbose about what you are doing and what fails?Best regards, Thorsten
smime.p7s
Description: S/MIME Cryptographic Signature
