Subject: Re: [nslu2-linux] Re: Anyone with success with Qemu? - SUCCESS! 
On Fri, 2005-07-22 at 07:18 +0000, emm_is wrote:


> vi: /lib/libc.so.6: version `GLIBC_2.3' not found (required by vi)
> vi: /lib/libc.so.6: version `GLIBC_2.3' not found (required by
> /usr/lib/libncurses.so.5)
> vi: /lib/libc.so.6: version `GLIBC_2.2' not found (required by
> /usr/lib/libncurses.so.5)

Hi, emm_is,

>From your next message, it looks like you figured this out for yourself,
but FYI: the glibc distributed with qemu-gnemul is an older version than
the version you will find on most recent linux desktop distributions.
Glibc versions are generally forwards compatible (unlike the bad old
days of linux libc) but not backwards. This means that binaries
compiled with an older glibc will run with a newer version, but not vice
versa - this is possible because of (among other things) the elf
versioning mechanism that is generating the errors you see. This
mechanism is distinct from, and more flexible than, versioning
mechanisms that involve the names of the libraries, but is specific to
the elf executable format, and requires support from the dynamic loader
(which is why you'll only see it being used in system libraries like
libc).

So, in short, if you want to run binaries that you have copied from a
recent linux desktop system, you will need to copy the libraries
from /lib, including the dynamic loader ("ld.so" or "ld-linux.so") and C
libraries, to the place where qemu expects to find them.

A quick way to do that is to mount your linux desktop's entire file
system on /opt/lib/gnemul with nfs. Don't do this unless you trust the
network between your desktop system and slug, and have a firewall
between it and the internet - nfs is not secure enough to be used over
an untrusted network.

The "unimplemented syscall" messages are probably a side-effect of
running a newer version of glibc, which uses linux syscalls that are not
yet implemented in qemu. It should be very easy to patch qemu to
implement them and pass the patches upstream to the qemu developers.
You can determine the name of the syscall from the number emitted by
qemu by consulting the file include/asm-i386/unistd.h in a current copy
of the sources of the linux kernel. Searching for that name in the
glibc and linux sources will then tell you how the syscall is being
used, and what its semantics are, respectively.