Since Dropbox is a closed source program, we must live with the binaries provided by dropbox. They only supply i386 and i386_64 binaries, and so ARM binaries, so it’s impossible to run it on, for example, my BeagleBoard.

But I was thinking, isn’t it possible to emulate an i386 CPU? I mean, there is a CPU emulator like Qemu, right? Even though it mentions

QEMU runs on x86 systems running Linux, Microsoft Windows, and some UNIX platforms, and can host target systems from a range of different microprocessors as detailed on the QEMU website

on http://en.wikibooks.org/wiki/QEMU, I attempted to compile it on my BeagleBoard. To save some time, I only compiled the i386 emulator for running ELF binaries. As it runs on an ArchLinux, which uses Python3 as default, I had to supply the path to the python executable as well.

./configure –python=/usr/bin/python2.7 –target-list=i386-linux-user

 And after a while it finished compiling.

[andre@beagle ~]$ uname -a
Linux beagle 3.1.6-1-ARCH #1 SMP PREEMPT Tue Jan 3 03:26:01 UTC 2012 armv7l ARMv7 Processor rev 3 (v7l) OMAP3 Beagle Board GNU/Linux
[andre@beagle ~]$ file ./hello.i386.static
./hello.i386.static: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=0x212eb3065d14823d2eb5d686604631b25201ff6e, not stripped
[andre@beagle ~]$ ./hello.i386.static
-bash: ./hello.i386.static: cannot execute binary file
[andre@beagle ~]$ qemu-i386 ./hello.i386.static
Hello World
[andre@beagle ~]$

Since I have no i386 libraries on the system yet, I have created a static executable on my i386 machine, and transferred it to my BeagleBoard. And it appears to work…

So…. let’s look at dropbox. What are the libraries it required?

[andre@myhost dropbox]$ ldd dropbox
    linux-gate.so.1 =>  (0xb771e000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb76e8000)
    libdl.so.2 => /lib/libdl.so.2 (0xb76e3000)
    libutil.so.1 => /lib/libutil.so.1 (0xb76df000)
    libm.so.6 => /lib/libm.so.6 (0xb76b3000)
    libssl.so.0.9.8 => /opt/dropbox/libssl.so.0.9.8 (0xb7671000)
    libcrypto.so.0.9.8 => /opt/dropbox/libcrypto.so.0.9.8 (0xb752e000)
    libc.so.6 => /lib/libc.so.6 (0xb738d000)
    /lib/ld-linux.so.2 (0xb771f000)
    libz.so.1 => /opt/dropbox/libz.so.1 (0xb7378000)
 

Well… just to make life simple for testing, I just copied the libraries from my running i386 system to the BeagleBoard. So we’re ready to go? Let’s see what happens?

[andre@beagle .dropbox-dist]$ qemu-i386 ./dropbox
/lib/ld-linux.so.2: No such file or directory

How to I tell Qemu where the libraries are. I have looked at the example here https://wiki.edubuntu.org/UbuntuDevelopment/Ports, and verified it with a dynamic version of the hello world executable, which seems to run fine

[andre@beagle ~]$ qemu-i386 libs-for-dropbox/ld-linux.so.2 –library-path libs-for-dropbox ./hello-i386-dynamic
Hello World

By placing the libraries in the .dropbox-dist directory, and using that path as library path, I also solved the issue where dropbox uses a script to use it’s own libraries. Are we ready to run?

[andre@beagle ~]$ qemu-i386 libs-for-dropbox/ld-linux.so.2 –library-path .dropbox-dist/  ./.dropbox-dist/dropbox
Traceback (most recent call last):
  File ““, line 5, in
zipimport.ZipImportError: not a Zip file

I think I should run it in it’s own directory

[andre@beagle .dropbox-dist]$ qemu-i386 ld-linux.so.2 –library-path /home/andre/.dropbox-dist/ ./dropbox
qemu: Unsupported syscall: 240
Traceback (most recent call last):
  File “__main__dropbox__.py”, line 27, in
  File “client_api/dropbox_connection.py”, line 22, in
  File “common_util/functions.py”, line 29, in
  File “common_util/dirtraverse.py”, line 303, in
  File “ctypes/util.py”, line 132, in find_library
  File “ctypes/util.py”, line 122, in _findLib_ldconfig
OSError: [Errno 22] Invalid argument

The Unsuppported syscall already made me think it won’t work… and a few seconds later, this was confirmed. The error messages also reveal something pythony is going on.  Apart from that snake, and the fact it’s not running, it appears some more library problems. Whether is is related to the unsupported syscall or missing libraries, as I see a find_library in there, I cannot tell yet.

So far for playing with my BeagleBoard (over the internet)

« »