Cross compiled binary won't run

Hello all. I am cross compiling for BBB under Ubunto Raring, trying to use a Linaro toolchain from Launchpad.

Reason to use this toolchain is I need gcc 4.8, since my code exposes, so the prepackaged Ubunto toolchain fails, since it is gcc 4.7.

The binaries compiled with this toolchain fail to execute, with strange symptoms:

root@beaglebone:~# uname -a
Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux
root@beaglebone:~# ls -l
total 3600
-rwxrwxrwx 1 root root 3679696 Jan 1 00:16 CloudSafe
drwxr-xr-x 2 root root 4096 Jan 1 00:01 Desktop
root@beaglebone:~# file CloudSafe
CloudSafe: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.1.1, BuildID[sha1]=0xb74d54b1daa09340f06bf9adb5a5a42e23a35b70, not stripped
root@beaglebone:~# ./CloudSafe
-sh: ./CloudSafe: No such file or directory
root@beaglebone:~# ldd CloudSafe
/usr/bin/ldd: line 116: ./CloudSafe: No such file or directory
root@beaglebone:~# strace ./CloudSafe
execve("./CloudSafe", ["./CloudSafe"], [/* 14 vars */]) = -1 ENOENT (No such file or directory)
write(2, “strace: exec: No such file or di”…, 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++

It seems the file is not there, even though i is very clearly three :frowning:
Other test programs cross compiled with the Ubuntu arm toolchain I get to run just fine.

Searcing for other questions like this in this forum leads me to believe this might be related to Hard Float… somehow… in a way I can’t understand.

Can someone enlighten me?

Can you try to compile your file/projcet with the option -static.

I got the same problem and in my case this works as first workaround.
I think the libraries on my computer (compile time) and on the BBB (runtime) are not at the same version.

I’m installing the latest Angstrom distribution to verify this.

Theoretically yes, of course, but this is not a feasible option for me as my app uses rather large libraries, starting with Boost.
I’d rather not have to build them on the PC, and the executable will be humongous…

I’d played some more with this, and I am convinced it is a problem with the Linaro toolchain. The older Linaro versions (gcc 4.7) have the same problem.
The error message is a bit off themark, though :slight_smile:

You only need to find the missing library and install them on the target.

As mentioned before the -static option is only a workaround. It’s only to see if this is the same problem as mine.

Do you now how i get ldd running on my target?
What package do I need to install in the Angstrom distribution?

It works for me now.
Instead of using the gcc tools from I followed now the following instructions and it works also without the static options.

Eh… What?

I’m not talking about the toolchain linked in those instructions or the toolchains.

My problem is specific with the Linaro gcc 4.8 toolchain.

(And to get ldd to work you just need to install it: opkg install ldd)

ldd doesn’t show up in the list of available packages on my BBB. But that’s an other story.

The only thing I would like to say was:
Find the right toolchaine to the installed libraries on your target
Install the right libraries on your target corresponding to your toolchain.


Wrong ABI. gnueabi should be the compiler you’re after not gnueabihf.

OK, so I’m now confused. Doesn’t the BBB have hardware floating point? I thought that was what the hf was for.

Let me backup a bit.

I run Debian on my own BBB’s here. A friend I know from IRC runs Angstrom and Ubuntu on his BBB. We tested this early on. I wrote a small app to run on my own BBB’s and it compiled and ran fine. I then sent the code, and executable to my friend, who then tried to run the executable on both Angstrom and Ubuntu. It worked for neither. But the code would compile and run fine natively.

For this purpose I used the gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_win32 executable. Yes, I cross compiled this on Windows 7 x64 ( despite being a win32 binary ). Also, I made zero changes to the toolchain. I ran it “stock”. No added lib’s , etc.

He just now told me that it is the wrong ABI. “Link it statically, and it will work”. Since he is the one who did all the checking, I have to assume he knows what he is talking about. Especially considering that he is a very experienced UNIX/Linux dev.

Anyway sorry for the half, and half cocked “answer”.

OK, I researched this a bit more… It seems the eabihf ABI is newer, and incompatible with eabi.
There has been some recent work in making busybox recognize this and give better error messages:

Couldn’t find any pre-built gcc 4.8 toolchains :frowning:

On the other hand, it turns out my code which caused gcc 4.7 to chrash was bad, and with 4.8 I got a decent error message instead of a crash. Which made it possible to fix the code, so now I don’t need 4.8 anymore :smiley:

Linaro toolchains use the ARM hard float as default .(i am sure about this from your link)

Angstrom use softfp as default (not sure about this )

If you need Linaro tools support soft fp , copy the files in the NONE hard float folder to default folder , this is the way I can only work around on iMX6 platform

And , you maybe need to change your CFLAG , by default , linaro toolchain optimized for Cortex-A9 , while BBB board is only have A8 core .


I also faced this issue. On my beaglebone with Ubuntu, the crosscompiled binary file can’t run. It shows: No such file or directory.
Finally I found a way to solve this issue. The cause is some runtime library can’t be found in beaglebone.
Check which library lack: Use ldd command

ubuntu@arm:~$ ldd S1 => /usr/lib/arm-linux-gnueabihf/ (0xb6e8d000) => /lib/arm-linux-gnueabihf/ (0xb6e6a000) => /lib/arm-linux-gnueabihf/ (0xb6d86000) => /lib/arm-linux-gnueabihf/ (0xb6d1b000)
/lib/ (0xb6f44000)

I check the library, not found. After search it in ubuntu package, the package name is: