“No such file or directory” when executing a cross-compiled program on a Raspberry Pi

Question

I recently bought a Raspberry Pi. I already have configured it, and I install a cross compiler for arm on my desktop (amd64). I compiled a simple "hello world" program and then I copy it from my desktop to my Pi with scp ./hello david@192.168.1.33:~/hello. After login in my Pi I run ls -l hello and I get a normal response:

-rwxr-xr-x 1 david david 6774 Nov 16 18:08 hello

But when I try to execute it, I get the following:

david@raspberry-pi:~$ ./hello
-bash: ./hello: No such file or directory

david@raspberry-pi:~$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6a926b4968b3e1a2118eeb6e656db3d21c73cf10, not stripped
david@raspberry-pi:~$ ldd hello 
    not a dynamic executable

Answer 1

If ldd says it is not a dynamic executable, then it was compiled for the wrong target.

Obviously you did cross-compile it, as file says is a 32-bit ARM executable. However, there's more than one "ARM" architecture, so possibly your toolchain was configured incorrectly.

If you are using crosstool-NG, have a look at the .config for the value of CT_ARCH_ARCH. For the raspberry pi, it should be "armv6j"¹ -- or at least, that's what's working for me. There are other specifics, but I think that should be enough. Unfortunately, if it's wrong, you now have to rebuild.

IMO getting a cross-compiler toolchain to work can be tedious and frustrating, but, presuming the host is not a significant factor (it shouldn't be), in this case it can be done. Crosstool-ng uses a TLI configurator, so if you end up having to try multiple builds, write down your choices each time so you know what worked.

¹ I believe armv7 is a much more common arch (lots of phones and such), so if you are just using something you believe is a generic ARM cross-compiler, that's probably the issue. These numbers are confusing as, e.g., the pi's processor is an ARM11, but (as per that page), the ARM11 family of processors uses the ARMv6 architecture -- i.e. ARM11 is an implementation of ARMv6.

Answer 2

How to identify the problem?

file cross_compiled_executable

Contains something like:

interpreter /lib/ld-uClibc.so.0

and the problem is that that file does not exist on the target.

How to solve the problem?

Use a proper compiler, either:

• the person who created the disk image must provide you the cross compiler or tell you exactly how to build it, e.g. with crosstool-ng. How to obtain it for RPI was asked here.
• compile your own image and cross compiler, e.g. with Buildroot. Here is a generic QEMU example. Buildroot has RPI support.

• use a native compiler on the target. But generally targets are much slower than your host, and space constrained, so you likely don't want to do this.

  You might also be able to use a functional emulator such as QEMU to build, and then only run the programs on a slower platform, e.g. gem5 or a slow board.

Just hacking up the interpreter is potentially not enough, notably you have to ensure binary compatibility between the program and the target libc, or program and kernel interfaces (syscalls, /proc, etc.) if you try to use -static (the target kernel might be too old and not contain the required interfaces). The only robust solution is to use the correct toolchain.

Answer 3

first compile your program with --static option, then test it. if it works as static then on raspberry pi

cat "programname" | grep "lib*"
/lib/ld-linux.so.3
libc6.so 

then check all libs if they are there

I have solved like this. I have /lib/ld-linux-armhf-so.3 but not /lib/ld-linux.so.3 then make a ln -s between then worked for me

Answer 4

The libraries on the target system differ from those of the host system your executable was compiled on / against.

You should include --static option in your CFLAGS and LDGLAGS if you're using make. If you're using straight gcc, use the --static option this way the executable is portable.