On Tue, Aug 3, 2010 at 11:16 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, Aug 02, 2010, Amit Kucheria wrote:
arm-linux-gnueabi-objdump: /lib/libm.so.6: File format not recognized dpkg-shlibdeps: error: arm-linux-gnueabi-objdump gave error exit status 1
This is a very recent new bug, which appeared between my testing and yours in the form of a new dpkg-dev! 1.15.8 and later introduce this issue, see Debian #591522.
There would be some ugly workarounds, but these aren't practical right now.
So I guess, native compilation is the only way out now, until this problem is solved?
On 08/05/2010 05:07 PM, Amit Kucheria wrote:
On Tue, Aug 3, 2010 at 11:16 PM, Loïc Minierloic.minier@linaro.org wrote:
On Mon, Aug 02, 2010, Amit Kucheria wrote:
arm-linux-gnueabi-objdump: /lib/libm.so.6: File format not recognized dpkg-shlibdeps: error: arm-linux-gnueabi-objdump gave error exit status 1
This is a very recent new bug, which appeared between my testing and yours in the form of a new dpkg-dev! 1.15.8 and later introduce this issue, see Debian #591522.
There would be some ugly workarounds, but these aren't practical right now.
So I guess, native compilation is the only way out now, until this problem is solved?
amit, I believe I have seen this problem on a x86_64 chroot (on a 64b machine) but using a 32b chroot on a 32b machine I didn't see it. what is your config?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591522
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thu, Aug 5, 2010 at 6:25 PM, Dechesne, Nicolas n-dechesne@ti.com wrote:
On 08/05/2010 05:07 PM, Amit Kucheria wrote:
On Tue, Aug 3, 2010 at 11:16 PM, Loďc Minierloic.minier@linaro.org wrote:
On Mon, Aug 02, 2010, Amit Kucheria wrote:
arm-linux-gnueabi-objdump: /lib/libm.so.6: File format not recognized dpkg-shlibdeps: error: arm-linux-gnueabi-objdump gave error exit status 1
This is a very recent new bug, which appeared between my testing and yours in the form of a new dpkg-dev! 1.15.8 and later introduce this issue, see Debian #591522.
There would be some ugly workarounds, but these aren't practical right now.
So I guess, native compilation is the only way out now, until this problem is solved?
amit, I believe I have seen this problem on a x86_64 chroot (on a 64b machine) but using a 32b chroot on a 32b machine I didn't see it. what is your config?
64-bit unfortunately. But thanks for the tip. I'll retry on a 32-bit install (will require a reinstall).
/Amit
On Thu, Aug 05, 2010, Amit Kucheria wrote:
So I guess, native compilation is the only way out now, until this problem is solved? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591522
Workaround: edit /usr/share/perl5/Dpkg/Shlibs/Objdump.pm and comment out:
if (get_build_arch() ne get_host_arch()) { my $od = debarch_to_gnutriplet(get_host_arch()) . "-objdump"; $OBJDUMP = $od if find_command($od); }
(Just after "our $OBJDUMP = "objdump";")
This is basically the old behavior of dpkg-dev when cross-compiling