I've built a custom 32-bit non-GUI Raspberry Pi image using Yocto (Morty), built the corresponding SDK, and used the SDK's toolchain to build an app. When I run the app on the RPi, from a command prompt as root, the shell complains:

-sh: /path/to/app: No such file or directory

(with the real app name, obviously). sh is linked to bash. Here's what I've checked:

  1. The app exists, and is the correct executable.

  2. Its execute permission bit is set.

  3. Its ELF file format is the same as the ELF file format of every other command in the system.

  4. The shared libraries it uses all exist, recursively, in /lib or /usr/lib. They are all listed by ldconfig -p.

  5. There is no LD_LIBRARY_PATH variable.

  6. If I run the app with LL_DEBUG=all, I get the same error, so it isn't even getting as far as loading libraries. (Or perhaps LL_DEBUG isn't supported on this build.)

Googling didn't turn up any other possibilities. Has anyone seen any other reasons for this error? Or any ideas on how to diagnose it further?

In response to techraf:

  1. If I had mistyped the name, I'd have gotten a "command not found" error. I tried running it by typing the full path. I also tried copying it into /bin and typing its name, in which case the error message showed the path in /bin.

  2. ls -l showed the x attribute.

  3. On the build system, arm-poky-linux-objdump -f (from the Yocto SDK) on the app executable showed file format elf32-littlearm, architecture: arm, flags 0x00000112, EXEC_P, HAS_SYMS, D_PAGED. If I did the same thing to, say, the ls command in the target rootfs in the build tree, it showed the same thing.

  4. Using arm-poky-linux-objdump -x on the executable and grepping for NEEDED, I listed all libraries needed by the app executable, then did the same thing on all those libraries in the rootfs, and built a combined list. I then did ldconfig -p on the RPi, and verified that every library that was needed was in the list with the correct versions. Here are the relevant items from the list:

    ld-linux-armhf.so.3 (ELF) => /lib/ld-linux-armhf.so.3 libasound.so.2 (libc6) => /usr/lib/libasound.so.2 libc.so.6 (ELF, OS ABI: Linux 3.2.0) => /lib/libc.so.6 libcrypto.so.1.0.0 (libc6) => /usr/lib/libcrypto.so.1.0.0 libdl.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libdl.so.2 libgcc_s.so.1 (libc6) => /lib/libgcc_s.so.1 libm.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libm.so.6 libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib/libpthread.so.0 librt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/librt.so.1 libstdc++.so.6 (libc6) => /usr/lib/libstdc++.so.6

    I don't know what the parenthesized items in the list mean, so maybe there's a clue there.

  5. I made sure there was no LD_LIBRARY_PATH variable.

  6. I tried running LL_DEBUG=all /path/to/app and got the same error, with no library loading trace.

I understand that the No such file or directory error often means a missing library, but I've made sure all the libraries are there and properly cached. So I'm wondering if anyone else knows any other possible cause for this error.

I created an empty C project (just return 0; inside main), and got the same error message. I used arm-poky-linux-objdump -x on both it and the chmod command, which is the smallest executable my build's /bin directory. Everything was the same other than section addresses and sizes, except that my dummy program has one .comment section and chmod has one .gnu_debuglink section. Even the .ARM.attributes sections have the same contents. Yet chmod loads and runs, while my test program won't load even far enough for ldd to output any shared library activity. There has to be something wrong with the SDK toolchain, even though it was generated as part of the Linux build.

  • Instead of describing what you think the state is, please show the methods you used to check and their results.
    – techraf
    Jun 24, 2017 at 1:07
  • I'm presuming stat /path/to/app using the exact path from the error proves this isn't just a typo or something...
    – goldilocks
    Jun 24, 2017 at 11:48
  • I've edited the post to show what I did to check things out. Jun 25, 2017 at 8:01
  • And goldilocks, stat-ing the file shows reasonable results. Jun 25, 2017 at 8:03
  • ldd /path/to/app?
    – BJ Black
    Jun 25, 2017 at 19:15

1 Answer 1


Someone on the Yocto list finally saw the problem: I was using the -mfloat-abi=hard option on the compile command, but I also needed to use the compiler to invoke the linker (instead of running ld directly), and use this same option.

The reason I didn't see this is that the program loader isn't listed in the object file as a NEEDED shared library. Instead, there's a string in a section called .interp that lists the name of the loader library.

Since I linked without -mfloat-abi=hard, it assumed softfp, which causes it to specify /lib/ld-linux.so.3 as the loader (which doesn't exist in my build) instead of /lib/ld-linux-armhf.so.3.

Thanks to all who tried to help.

  • Please accept your own answer with a click on the tick on its left side. Only this will finish the question and it will not pop up again year for year.
    – Ingo
    Jan 15, 2020 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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