On Sun, 13 May 2007, Sam Hartman wrote: > Package: dpkg-dev > Version: 1.13.25 > Severity: normal > > I have an i386 system with both i386 and amd64 libraries in > /etc/ld.so.conf. This is useful because it makes it easier to run > amd64 binaries. Modern ld.so will just skip libraries of architecture > that conflict with the executable. However, dpkg-shlibdeps runs > objdump, which complains if the format is unrecognized. > So, dpkg-shlibdeps always fails on my system because it finds > /lib64/libc.so.6 before /lib/libc.so.6.
Can you precise how we can more generally reproduce that? It doesn't seem to be reproducible with current unstable. 1/ First off it looks like amd64 binaries are nowadays recognized by i386's objdump... so your failure case might have disappeared. In fact, I tested with a powerpc library and objdump didn't fail on it either. 2/ Then I tried to put the powerpc libc first in my LD_LIBRARY_PATH and it looks like ld.so doesn't skip over it like you say. Instead I got failures like: /usr/bin/perl: error while loading shared libraries: /home/rhertzog/tmp/libc/lib/libdl.so.2: ELF file data encoding not little-endian Doing the same with an amd64 lib effectively works, but that means that the principle is not applicable to all arches... It's true that a failure of "objdump -a" will lead to the end of dpkg-shlibdeps. However I'm reluctant to remove the failure case now that objdump is apparently able to parse correctly more formats. So I'd suggest closing this bug. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
