On Tue, Aug 03, 2010, Raphael Hertzog wrote: > 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?
I wonder whether it makes sense to look into /usr/lib at all when cross-building? Perhaps we should patch the routine which prepares a list of files to analyze to not search usr/lib when cross-building? I'm not sure where that one is. If that's not an option, I think the routine checking the format of executable could run the cross-objdump and if it fails try the host objdump as a fallback. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
