I've managed to run hello world (static at the moment) which is an x86 binary, on my n900 using qemu's user linux mode.

?:/home/opt/root# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, statically linked, stripped
?:/home/opt/root# file `which file`
/usr/bin/file: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), stripped
?:/home/opt/root# ./qemu-i386-2 ./hello
Hello World
?:/home/opt/root#

Next up, dynamically linked stuff, and then wine ))

Now with a stock GNU ls from an x86 box, dynamically linked.

?:/home/opt/root/lib# ../qemu-i386-2 ./ld-linux.so.2 --library-path `pwd` ../ls
qemu: Unsupported syscall: 240
ld-linux.so.2 libattr.so.1 libdl.so.2 librt.so.1
libacl.so.1 libc.so.6 libpthread.so.0 libselinux.so.1
?:/home/opt/root/lib#

Don't know what Unsupported syscall: 240 is, but it seems to work and correctly lists files.

A call to system library that is ARM EABI?

My wineserver and wine attempts are failing sadly.

?:/home/opt/root/standalonewine-0.99# strace -s256 -v -fF -o log ../qemu-i386-2 $MYWINEPATH/ld-linux.so.2 --library-path $LDLIBRARY_PATH $MYWINEPATH/wine-pthread
qemu: Unsupported syscall: 240
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

I happened to already have an ld-linux.so spawned wine and wineserver shell wrapper from a different project running missmatched system compiled binaries. However that was on the same arch. This isn't working.

#!/bin/bash
export MYWINEPATH=`pwd`
export WINEPREFIX=`pwd`
export WINEDLLPATH=$MYWINEPATH/dlls
export LDLIBRARY_PATH=$MYWINEPATH/libs
../qemu-i386-2 $MYWINEPATH/ld-linux.so.2 --library-path $LDLIBRARY_PATH $MYWINEPATH/wineserver.bin

Anyone have any ideas what to try next? qemu mailing list, wine mailing list ?

Hve you tried looking into the core dump? Even debugging it?

which qemu version are you using?
You could try to get wine running on a x86 host (x86 on qemu on x86) first.

With the following

mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
echo ':i386:M::\x7fELF\x01\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x02\x00\x03:\xff\xff\xff\xff\xff\x fe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff \xff:/home/user/qemu-i386:' >/proc/sys/fs/binfmt_misc/register
echo LD_LIBRARY_PATH=/opt/root/x
~/wine/usr/lib/wine $ file /lib/ld-l*
~/wine/usr/lib/wine $ file -L /lib/ld-l*
/lib/ld-linux.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
/lib/ld-linux.so.3: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), stripped
~/wine/usr/lib/wine $

I can simply run arm or x86 linux binaries with reasonable success. fork/clone don't work so wine can't run stuff but will execute:

~/wine/usr/lib/wine $ /usr/bin/file /usr/bin/file
/usr/bin/file: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), stripped
~/wine/usr/lib/wine $ file ../../bin/wine
../../bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, dynamically linked (uses shared libs), stripped
~/wine/usr/lib/wine $ wine
qemu: Unsupported syscall: 240
Usage: wine PROGRAM [ARGUMENTS...] Run the specified program
wine --help Display this help and exit
wine --version Output version information and exit
~/wine/usr/lib/wine $ wine --version
qemu: Unsupported syscall: 240
wine-1.1.29

There are two things here :

- The unsupported syscall 240 is __NR_futex. The problem is that QEMU doesn't support NPTL for x86. This will certainly cause some problems with clone.

- You shouldn't mix host and guest files in the same place! Copy an x86 filesystem somewhere, and chroot into it from inside QEMU. That's the safest way of doing things

I'm following this thread with much interest. Please keep us updated on your attempts.

2d

Thanks, I've also (yesterday) heard the same about NPTL from the qemu developers list. Simply my use of particular userland libs could be causing me the issues. I might try and find quite old dists to compile against or just nick binaries from.

As for mixing stuff, well I was segregating with ./ld-linux.so.3 --library-path ... ./binary which is not quite chrooted but as separate as safe. But mixing was cool and I know the dangers I've also been unable to get chroot (busybox) to work as I expected it, I get /bin/sh no such file or directory despite there being a bin/sh in the /place/ I'm chrooting to.

Sadly I'm away for 3 weeks now with probably limited connectivity. I encourage others to try what I've checked out. Qemu peeps say my override of __clear_cache() was okay, so the qemu-i386 binary is safe to use, if somebody wants a copy it's wgetable from this url: http://a.trap.me.uk/qemu-i386 - they also agree a p90 was reasonable speed to expect (excluding any floating point). My experience with xeyes and topper show that graphically it's nifty and well worth investigating.

The rest of this thread should help the rest of the set up, most people will have the right libs and files lying around.