2016-01-17 6:58 GMT+01:00 Marco d'Itri <m...@linux.it>:
> On Jan 12, Guillem Jover <guil...@debian.org> wrote:
>
>> Check your /etc/ld.so.conf.d/* for anything included libx32, and check
>> if «dpkg-query --search» knows about that pathname, and if it's the
>> canonical one or a symlinked one.
> I still do not fully understand how dpkg-shlibdeps determines the full
> library path from the NEEDED ELF entries, but how can it work if the
> libraries which are installed in /usr/lib/... now appear in /lib/...?
Here's the stuff I think that happens:
file /tmp/perf-read-vdsox32
/tmp/perf-read-vdsox32: ELF 32-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for
GNU/Linux 3.4.0,
BuildID[sha1]=08e989782c6b565fed78770acdb690f86123e6a1, stripped
file /tmp/perf-read-vdso32
/tmp/perf-read-vdso32: ELF 32-bit LSB executable, Intel 80386, version
1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for
GNU/Linux 2.6.32,
BuildID[sha1]=3c770afba2f8bdf603ed3372ee2695c4f565b0b0, stripped
The code seems to be compiled for different architectures, and
dpkg-shlibdeps knows that from analyzing the ELF binary, but then
searches the libc and other dependencies in the paths it finds on the
current system, resulting it not finding the right software (since the
dpkg database still lists these binaries in the non-usrmerge
directories).
On i386, it also searches in the wrong path, but in that case I am not
sure why this fails on this package but not on others:
```
dpkg-shlibdeps: error: no dependency information found for
/usr/lib/ld-linux.so.2 (used by
debian/liblockdep4.4/usr/lib/i386-linux-gnu/liblockdep.so.4.4)
```
Cheers,
Matthias
