On Tue, 03 Aug 2010, Simon Richter wrote: > while using the target objdump is a Good Thing(tm), it uncovered another > bug: for dependent libraries, the host's version is passed to the target > objdump.
That's not really accurate, it's passed to objdump -a only to verify if the binary has the same format than the executable analyzed. The full analysis comes only later if there's a match. > While this looks like a regression as builds that used to work now fail, > it isn't, because the builds were only correct by chance before. > > Symptom is that during a cross build of a library that links against > libutil, the following is output: > > m68k-linux-gnu-objdump: /lib/libutil.so.1: File format not recognized > dpkg-shlibdeps: error: m68k-linux-gnu-objdump gave error exit status 1 > > The correct file would be /usr/m68k-linux-gnu/lib/libutil.so.1 . The > path can be retrieved from the target gcc using the -print-search-dirs > option. dpkg-shlibdeps looks in the correct path as well. But it really needs a portable way to know whether a file has been built for the same architecture than the executable analyzed. It tries to do this with objdump -a and with binutils-multiarch that was working fine. It would then detect that it was the wrong version and would continue to look for the correct library. Loïc, what do you suggest? Should we parse the error instead? And/or fallback to the host objdump? Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
