reassign 317082 libc6-dev,dpkg-dev thanks I managed to grab Matthias Klose and he helped me get a working demo of the problem on my lowly i386, and I understand the bug now -- there's some missing context in the above mails. 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. Build yourself a quick demo (on ubuntu breezy i386): $ sudo aptitude install libc6-dev-amd64 $ apt-get source zlib $ cd zlib # edit debian/rules: add i386 to 64-ARCHS # edit debian/control: add i386 to Architecture of lib64z1 and lib64z1-dev $ debian/rules build $ fakeroot debian/rules binary 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. I don't think this is just a dpkg-dev bug, these "bi-arch" systems need to provide ldd or an equivalent that can read either form of shared library that it would support. objdump isn't a solution either, while it sometimes can read the other shared library, it doesn't provide the linker search patch which is of critical importance to get this stuff right. So I'm including libc6-dev (for want of a better package) in this bug, as we first need ldd on these bi-arch systems (or something similar) for dpkg-shlibdeps to use before we can fix that! Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part