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?
signature.asc
Description: This is a digitally signed message part
