2

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.

Rohit Gupta
  • 343
  • 2
  • 4
  • 11
Paul DeRocco
  • 129
  • 2

1 Answers1

0

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.

Paul DeRocco
  • 129
  • 2