On 05-Aug-17 17:00, Scott James Remnant wrote: > For those following, the problem is that people are building 64-bit > libraries on a 32-bit platform (or the other way around) as part of the > package build. dpkg-shlibdeps uses plain old "ldd" to find out the > dependencies of a binary or shared library, but the ldd on the system > won't be able to identify the impostor libraries.
> This'll fail with: > dpkg_shlibdeps -p lib64z1 -lbuild-tree/zlib-1.2.3 > /usr/bin/ldd: line 161: /lib64/ld-linux-x86-64.so.2: cannot execute > binary file > dpkg-shlibdeps: failure: ldd on > `debian/lib64z1/usr/lib64/libz.so.1.2.3' gave error exit status 1 > dh_shlibdeps: command returned error code 256 > > > In this example, the 32-bit i386 ldd on my system can't read the amd64 > binaries that have been generated. Please 'apt-get install amd64-libs' and try this again. 'ldd' should work then. The current 'ldd' already supports biarch. However, to work for 64-bit binaries, 'ldd' needs the 64-bit linker '/lib64/ld-linux-x86-64.so.2'. This linker is currently in 'amd64-libs' (this may change to 'libc6-amd64' later). This means that the problem can be solved by always installing 'amd64-libs' (or 'libc6-amd64') before dpkg-shlibdeps is used for a 64-bit binary. Generally, a package which creates 64-bit binaries on i386 will have to Build-Depend on 'amd64-libs-dev' or 'libc6-dev-amd64' anyway, because it needs to link to a 64-bit libc. In this case there is no problem. In the case of the 'glibc' package itself, I think a Build-Depends on 'amd64-libs-dev [i386]' (or 'libc6-dev-amd64 [i386]') should be added. The same applies to the other biarch cases (powerpc, sparc, s390). This should fix the bug. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]