On Tue, 11 May 2010, Richard Henderson wrote: > On 05/11/2010 10:08 AM, Damion Yates wrote: > > Also is there some magic in gnemul-x86 beyond being a set of x86 > > libs? > > No.
Okay, good to know. > > Does it do any shortcutting to system calls in native rather than > > sticking with the libs under emulation more? > > No. Okay, fine. I expect this has been thought of (or dismissed as not feasible) on the qemu mailing list over the years anyway. > > Could you explain what you did? I've tried the following: > > Use the binfmt_misc filesystem to set up qemu as the interpreter for > x86 binaries. Did that (mentioned in the original email). I think what I must have missed was making sure the qemu binary was found in matching paths in the chroot (in fact it's probably not needed outside the chroot really). I'm not quite sure how I missed that, I know what I'm doing but I think I just lacked faith in whether this could work at all on a fundamental level. Of course that was since confirmed on this list, so I just needed to try again harder. > > chroot ch/ ./ld-linux-arm.so --library-path `pwd`/armlibs \ > > ./qemu-i386 bin/sh > > You may find it easier to staticly link the arm qemu in that case. Yeah, I figured this was going to be the only way, it was that or the interpreter after the #! within any wrapper to run stuff. As I didn't even have a static sh (arm) around, I rechecked the build of qemu and found it trivial to statically compile*. I've now got it working as planned, I can chroot in, I've bind mounted /tmp/.X11-unix/ in to the chroot so X works (I think my phone has X with -nolisten tcp and changing that is phone-brickingly scary). So yeah... everything sort of works. I can run arbitrary (fairly) complex binaries like screen, xterm (both need to fork), graphical stuff like XV and of course wine sol.exe (which I think does some threading)! http://www.youtube.com/damionyates2 Thanks for all your help. I still have some issues, surprisingly a few reboots, which is odd as I'm su'ed to a user after needing root for the chroot, I suspect something I'm mapping with /dev/ or /proc/ mounts. I've found although a lot of stuff doesn't work if it needs those mounts working, my tests are more reliable for the binaries that don't need /proc or /dev being there, if I don't mount /proc or bindmount /dev/pts at all. It's also not quite doing what I want in terms of wine capabilities. I suspect the revisions of x86 libs and wine version, possibly NPTL. But I think the wine mailing list is the next best stop for me for that unless any of you are particularly interested in this? The other threads on this list are all developery with loads of patches and stuff so I'll stop annoying you all now and close this thread as a success :) Damion *This is increasingly hard, I think many modern GNU projects have given up providing a way to statically link stuff, and so many things pull in via dlopen now you can't even tell from an ldd whether it's likely to work. -- Damion Yates - Google UK Ltd Belgrave House, 76 Buckingham Palace Rd, London SW1W 9TQ - reg:3977902
