On Wed, Aug 28, 2013 at 04:35:52PM +0200, Alessandro Ghedini wrote: > On gio, ago 22, 2013 at 11:08:47 +0300, Riku Voipio wrote: > Is this actually possible? I mean, doesn't the "hf" (hard float) part in armhf > make armhf packages incompatible with armel hardware (even if ARMv7 and using > multiarch)?
If you have a ARMv7 hardware, you can run armhf binaries, even if the systems is armel. Just tested on armel chroot on arndale (ARMv7): # dpkg --add-architecture armhf # apt-get update # apt-get install valgrind:armhf ... # valgrind --version valgrind-3.8.1 # ... But it turns out valgrind still won't work due to trying to LD_PRELOAD armhf libraries to armel binary (notice the ld.so warnings): # valgrind ./test ==9719== Memcheck, a memory error detector ==9719== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==9719== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==9719== Command: ./test ==9719== ERROR: ld.so: object '/usr/lib/valgrind/vgpreload_core-arm-linux.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object '/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so' from LD_PRELOAD cannot be preloaded: ignored. ==9719== Syscall param exit_group(status) contains uninitialised byte(s) ==9719== at 0x48C6954: _Exit (_exit.c:32) ==9719== by 0x485BD67: __run_exit_handlers (exit.c:92) ==9719== by 0x485BD8F: exit (exit.c:99) ==9719== by 0x48410CF: (below main) (libc-start.c:294) ==9719== ==9719== ==9719== HEAP SUMMARY: ==9719== in use at exit: 0 bytes in 0 blocks ==9719== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==9719== ==9719== All heap blocks were freed -- no leaks are possible ==9719== ==9719== For counts of detected and suppressed errors, rerun with: -v ==9719== Use --track-origins=yes to see where uninitialised values come from ==9719== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Riku -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
