cross compilation for ARM: error no such file or directory

Question

I have written simple Hello world program and compiled it with gcc-arm-linux-gnueabi compiler. It compiles well but when i try to execute it on ARM machine it complains "no such file or directory". I think gcc-arm-linux-gnueabi is for embedded Linux only due to e(mbedded)abi. Is it different from ARM Linux ABI?

Please help me to solve this problem

code is here

#include "stdio.h"

int main(void) {
  printf("Hello world !\n");
  return 0;
}

compiled as

> arm-linux-gnueabi-gcc -Wall -o crosscomp hello.c

When i execute this crosscomp on target ARM machine error is crosscomp no such file or dir

EDIT When I was using arm-linux-gnueabi-gcc the entry point was not matching with the target machine entry point (readelf -l crosscom) but when I compiled with aarch64-linux-gnu-gcc entry point matched with target machine. But now error becomes permission denied on ./crosscomp. I tried with sudo which says crosscomp: no such command.

Answer 1

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.
• compile your own image and cross compiler, e.g. with Buildroot. Here is an example.

• 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.