01.12.2013 23:27, Marc Glisse wrote: [] > I managed to run: > $ qemu-ppc-static /lib/powerpc-linux-gnu/libc.so.6 > > which prints the usual text, but so far that's the only program that > hasn't failed with: > > $ qemu-ppc-static ./bin/true > Invalid data memory access: 0xb6d15008 [...]
> Other people seem to have more luck, but I have mostly read posts about > debootstrap or chroots, not about multiarch setups. I've never tried multiarch setup, never ever considered it. Only on second read of your bugreport I realized you're not running it in chroot but on real root with multiarch instead. And now I realize that I don't even know how to do that. I don't really want to mess with my regular system (unless it is something easy, like just libc6), so it looks I'll have to try multiarch-within-chroot. Can you provide some details about how this kind of multiarch system can be set up, pleae? Note: I verified several arches from qemu-user-static in foreign chroots (using debootstrap --arch=powerpc in this case), and it works quite well. But it never occured to me to test in a live system.. > According to strace, the segfault happens just after closing > /etc/ld.so.cache. On arm, that's followed by a second check for > /etc/ld.so.nohwcap and then looking everywhere for libc.so.6. Might it be due to some differences within ld.so.cache? I mean, when it has stuff from several architectures, does the runtime linker actually work right? I dunno. Thank you for the bugreport! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
