Edit for people looking this up in the future: My understanding right now is the "No such file or directory" is misleading. If you have an elf, you run it by chmod a+x and ./programname.elf. The reason it failed on my system is that elf can mean(and does in this case), that you have a dynamically linked executable. Because the SDK I used linked dynamically, the source code for the 3rd party functions used by the SDK are not built into the elf. A dynamic linked executable simply looks for all the required includes when it is run, a static linked executable has all the required code written into the binary when it is compiled. The solution to my problem seems to be either figure out how to make the SDK compile my program statically, or figure out how to make a statically linked library containing the relevant functions I need and build my program natively on my target platform using that.

I try to run an elf with bash./program.elf, but get response "cannot execute binary file".

Running file program.elf gives

file.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped

Running uname -a gives

Linux analog 3.19.0-g7f929ec #1 SMP PREEMPT Thu Sep 3 18:06:48 EEST 2015 armv71 armv71 armv71 GNU/Linux

Both say ARM, so why does this program not work?

At someone's suggestion, here is readelf-A ./program.elf

Attribute Section: aeabi
File Attributes
    Tag_CPU_name: "7-A"
    Tag_CPU_arch: v7
    Tag_CPU_arch_profile: Application
    Tag_ARM_ISA_use: Yes
    Tag_FP_arch: VFPv3
    Tag_Advanced_SIMD_arch: NEONv1
    Tag_ABI_PCS_wchar_t: 4
    Tag_ABI_FP_rounding: Needed
    Tag_ABI_FP_denomal: Needed
    Tag_ABI_FP_exceptions: Needed
    Tag_ABI_FP_number_model: IEEE 754
    Tag_ABI_align_needed: 8-byte
    Tag_ABI_enum_size: int
    Tag_ABI_HardFP_use: SP and DP

closed as unclear what you're asking by Gilles, slm Jul 13 '16 at 2:07

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Did you compile this program? What is the output of readelf -A ./program.elf? There are a number of Arm versions. ARMv2, ARMv3, ARMv5, ARMv7... hard-float and soft-float ABI: etc. – jc__ Jul 12 '16 at 17:38
  • Looking at this site (wiki.debian.org/ArmEabiPort) it looks like it ..:should:.. work. May need to chase down the compiler options vs your hardware. – jc__ Jul 12 '16 at 17:54
  • I compiled the program on a different computer using an SDK, but that SDK is provided by the makers of the processor I'm using, so I would imagine that their SDK ought to have the build configurations to target their own chip, correct? – Zephyr Jul 12 '16 at 17:57
  • That would be my guess too, but the SDK could be used for multiple µP. Still check the readelf -A ./program.elf info to verify. Is there more to the error than "cannot execute binary file"? – jc__ Jul 12 '16 at 18:08
  • 2
    Wait. bash ./program.elf? The elf file is NOT a bash script. Dont run it through the bash interpreter. It is an elf file ./program.elf. Assume execute bit set. chmod a+x ./program.elf. – jc__ Jul 12 '16 at 18:36

The command bash ./program.elf will send the file through the bash interpreter.

An elf file is a compiled binary file and should run from the command line like so: ./program.elf

Do not forget to set the executable bit for the file with:

chmod a+x ./program.elf

From what I can tell it is far more common for an ARMv7 processor to be the model ARMv7-A (the kind used for the Snapdragon 600/800 in the Galaxy S4 and Nexus 5 respectively, as well as the Raspberry Pi 2/model B), however your output lists the system chip as an ARMv71 (a.k.a. the ARMv7 Revision 1). It seems entirely possible that the variant of the ARMv7 processor SDK you selected when compiling/building the program was simply the wrong subset of ARMv7, similar to if you had meant to build for ARMv7-A and instead built for ARMv7-M. Now this is only a guess as I have no idea what processor/device you were building for, or building on for that matter, but given how picky SoC processors are when it comes to running programs not compiled specificly for them I would suggest compiling source directly on the machine in question if possible.

  • Compiling natively was my first thought, but trying to do that brought up a different set of problems that I'm also trying to solve. The chip I am using is a Xilinx processor, and I am compiling on Xilinx SDK on a Windows computer. I had assumed that Xilinx SDK should compile for the right architecture for the ARM they use in Xilinx processors, so it's weird to me that that doesn't seem to be the case. – Zephyr Jul 12 '16 at 18:30
  • Looking into it it seems as though Xilinx has several families of processor, all of which fall under the ARMv7x category, but utilize different combinations of various arm cores that are often found in ARMv7 cpus. For example one model may have two A9-Cortexes and an A7-Cortex as a secondary co-processor, while another may have one A8-Cortex with another single A5-Cortex as its co-processor. (I have no idea if these are real combos present in Xilinx CPUs, just examples :P – Alison E.E. Jul 12 '16 at 19:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.