Cross-Compiled GNU ARM (BeagleBoneBlack) from Windows. Runtime Error on *.elf: "No such file or directory"

Question

I'm in the (very) early stages of developing a UAV flight controller on a BeagleBone Black. I should mention that I'm quite the novice when it comes to the BBB, Linux and embedded systems.My academic focus has been on control theory - this is my first attempt at a practical implementation outside of Matlab Simulations. My current system is as follows:

Host-> Windows 8.1 x64 running Eclipse Luna (4.4.0)
Target -> BeagleBone Black rev. B running Ubuntu 13.10

Target Info

root@arm:~# uname -a
Linux arm 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 armv7l armv7l         armv7l GNU/Linux

Target gcc version

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/shar
e/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8
 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --w
ith-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enabl
e-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --ena
ble-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr
/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf --
with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/ja
va/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-
a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-lin
ux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)

I've installed the Sourcery Codebench Lite toolchain and am using the GNU Make file. I’ve set up the Eclipse environment as per the instructional video provided by Michael Jantz (link removed due to limit - if interested search "Cross-Compile and Remote Browsing for BeagleBone" on YouTube) with some minor tweaks to get it running on my system. These tweaks consisted primarily of removing the "--specs=rdimon.specs" and "-lrdimon" linking flags as I kept getting a "no such file or directory" when compiling. With these two flags removed the simple "Hello ARM World" program compiles without any issues.

After transferring the compiled ELF file to my BeagleBone, setting permissions and the executable flags via:

chmod ugo-x Test6.elf

and running it via:

./Test6.elf

I get the following message:

root@arm:/home/ubuntu/RDKTestProgs# ./Test6.elf
bash: ./Test6.elf: No such file or directory

I initially thought the mismatch between my 64-bit host system and the 32-bit GNU Make shouldn’t be an issue, but to eliminate my doubt I found a 64-bit GNU Make file (link removed due to limit) although I’m not sure of its integrity. In any case, both GNU Make files yield the same result when trying to execute the program on the BBB.

After looking through a several posts I discovered the “ readelf“, “strace” and “strings” tools, which yielded the following outputs.

Readelf:

root@arm:/home/ubuntu/RDKTestProgs# readelf -d Test6.elf 
 Dynamic section at offset 0x858 contains 27 entries:
 Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x0000000c (INIT)                       0x8550
 0x0000000d (FINI)                       0x87a0
 0x00000019 (INIT_ARRAY)                 0x10848
 0x0000001b (INIT_ARRAYSZ)               8 (bytes)
 0x0000001a (FINI_ARRAY)                 0x10850
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0x8168
 0x00000005 (STRTAB)                     0x82bc
 0x00000006 (SYMTAB)                     0x81bc
 0x0000000a (STRSZ)                      444 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x10958
 0x00000002 (PLTRELSZ)                   72 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8508
 0x00000011 (REL)                        0x84f8
 0x00000012 (RELSZ)                      16 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x8498
 0x6fffffff (VERNEEDNUM)                 3
 0x6ffffff0 (VERSYM)                     0x8478
 0x00000000 (NULL)                       0x0
root@arm:/home/ubuntu/RDKTestProgs# strings Test6.elf
/lib/ld-linux.so.3
libc.so.6
abort
__libc_start_main
__aeabi_atexit
libstdc++.so.6
__gmon_start__
_Jv_RegisterClasses
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
_ITM_deregisterTMCloneTable
_ITM_registerTMCloneTable
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
_ZNSt8ios_base4InitD1Ev
_ZNSolsEPFRSoS_E
_ZNSt8ios_base4InitC1Ev
_ZSt4cout
libm.so.6
libgcc_s.so.1
__aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr1
GLIBCXX_3.4
GCC_3.5
GLIBC_2.4
?8FAFJF
x`9`{h
Hello ARM World!

Strace:

root@arm:/home/ubuntu/RDKTestProgs# strace ./Test6
strace: Can't stat './Test6': No such file or directory
root@arm:/home/ubuntu/RDKTestProgs# strace ./Test6.elf
execve("./Test6.elf", ["./Test6.elf"], [/* 22 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 +++

Strings:

root@arm:/home/ubuntu/RDKTestProgs# strings Test6.elf
/lib/ld-linux.so.3
libc.so.6
abort
__libc_start_main
__aeabi_atexit
libstdc++.so.6
__gmon_start__
_Jv_RegisterClasses
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
_ITM_deregisterTMCloneTable
_ITM_registerTMCloneTable
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
_ZNSt8ios_base4InitD1Ev
_ZNSolsEPFRSoS_E
_ZNSt8ios_base4InitC1Ev
_ZSt4cout
libm.so.6
libgcc_s.so.1
__aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr1
GLIBCXX_3.4
GCC_3.5
GLIBC_2.4
?8FAFJF
x`9`{h
Hello ARM World!

I searched through my BeagelBoneBlack for the 4 shared library files indicated from the “readelf” function and found that they are in fact present. The issue is however, that some of these files are found in the usr/lib/arm-linux-gnueabihf/directory whereas others are found in the /lib/arm-linux-gnueabihf# directory. To fix this I created symbolic links to the files not found in the /usr/lib/arm-linux-gnueabihf/ directory. This still did not solve the problem. So I created symbolic links to files not found in the /lib/arm-linux-gnueabihf/ directory. Again, no luck.

Is there a way to check which directory is being used on execution? What else could possibly be missing from the Test6.elf file? I’m at a loss at the moment. Any advice or guidance would be greatly appreciated! Cheers!

P.S. I also managed to check for the GLIBCXX_3.4, GLIBC_2.4 and GCC_3.5 as shown below, but again, some of these pertain to files in /usr/lib/arm-linux-gnueabihf others are found in the /lib/arm-linux-gnueabihf. Thanks again!

root@arm:/lib/arm-linux-gnueabihf# strings libgcc_s.so.1 | grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.3.4
GCC_3.4
GCC_3.4.2
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0
GCC_4.7.0
GCC_3.5

root@arm:/usr/lib/arm-linux-gnueabihf# strings libstdc++.so.6.0.18 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBC_2.4
GLIBC_2.17
GLIBCXX_DEBUG_MESSAGE_LENGTH

And finally, here's the "Hello ARM World" program

//============================================================================
// Name        : main.cpp
// Author      : RDK
// Version     :
// Copyright   : Your copyright notice
// Description : Hello World in C++
//============================================================================

#include <iostream>
using namespace std;

//
// Print a greeting message on standard output and exit.
//
// On embedded platforms this might require semi-hosting or similar.
//
// For example, for toolchains derived from GNU Tools for Embedded,
// to enable semi-hosting, the following was added to the linker:
//
// --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group
//
// Adjust it for other toolchains.
//

int
main()
{
  cout << "Hello ARM World!" << endl;
  return 0;
}

Answer 1

Right on! So I've got it working. Here are my steps, hopefully they're sound and wont cause me issues in the future.

1. From this post, I tried to find out where the Test6.elf expected to find the linux loader for dynamically linked libraries. This yielded:

   root@arm:/home/ubuntu/RDKTestProgs# readelf -l ./Test6.elf | grep ld-linux [Requesting program interpreter: /lib/ld-linux.so.3]

2. I checked my /lib folder and sure enough the ld-linux.so.3 file was missing. Instead I found it in the /lib/arm-linux-gnueabihf/ folder

3. So I created a symbolic link in the /lib folder via:

   ln -s /lib/arm-linux-gnueabihf/ld-linux.so.3 /lib/ld-linux.so.3

And boom! It works. What I still find strange however is that the ldd ./Test6.elf still returns:

 root@arm:/home/ubuntu/RDKTestProgs# ldd ./Test6.elf
 not a dynamic executable

Is there a good reason for this, or is this somehow normal? - It doesn't seem right to me.

I also noticed that my current compiler settings (and hence toolchain) for Float ABI are set to soft, yet my BeagleBoneBlack is running arm-linux-gnueabihf - hard float. Will this cause me problems in the future? Should I be looking for a different toolchain?

Cheers!