Bug#317082: Not just a dpkg bug
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
Reply to: