[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

The same applies to the other biarch cases (powerpc, sparc, s390).

This should fix the bug.

Andreas Jochens

Reply to: