6
  1. I'm using the Ubuntu in UserLAnd on an android.
  2. I just installed from the Android SDK Manager sdkmanager cmake 3.18.1.

Now, I can see the cmake executable from its directory cmake/3.18.1/bin byls, but when I run ./cmake, bash returns bash: ./cmake: No such file or directory. What went wrong? The full output from console:

ubuntu@me:~/cmake/3.18.1/bin$ ls
ccmake  cmake  cpack  ctest  ninja

ubuntu@me:~/cmake/3.18.1/bin$ ./cmake
bash: ./cmake: No such file or directory


ubuntu@me:~/cmake/3.18.1/bin$ file ./cmake
./cmake: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, stripped


ubuntu@me:~/cmake/3.18.1/bin$ ldd ./cmake
        not a dynamic executable


ubuntu@me:~/cmake/3.18.1/bin$ uname -m

        aarch64

Thanks!

wicstas
  • 79

1 Answers1

20

This confusing error, no file found, is what you get if you try to run a binary compiled for a different architecture. In your case, you are running on an AArch64 system, on an ARM chip. However, your binary was compiled for x86-64, an architecture used in Intel and AMD chips (possibly others too).

In short, you cannot execute this binary on your system. Instead, you need to download a version compiled for AArch64 or compile it yourself from source.

Ismael Miguel
  • 164
terdon
  • 100,812
  • This error can also be generated from the linker. If a library isn't located, it will also generate "No such file or directory." – Christian Nov 12 '23 at 13:27
  • 5
    That's certainly a misleading error message. – RonJohn Nov 12 '23 at 15:33
  • @RonJohn It's not just confusing, I'd argue that it's a bug: " [ENOEXEC] The new process image file has the appropriate access permission but has an unrecognized format." Note, though, the caveat: "The exec functions, except for execlp() and execvp()". I'd argue that using one of those when the path to the executable is specified is also a bug. – Andrew Henle Nov 12 '23 at 16:04
  • @Christian: Only if the dynamic linker (ELF interpreter ld.so) is not found will execve itself return -ENOENT. Otherwise the exec will succeed but a later system call will fail. Use file, or readelf -l ./foo | grep Requesting, to check the path. How does execve call dynamic linker/loader (ld-linux.so.2) Fun fact: on x86-64 Linux, the Binutils default for ld foo.o -lc is different from the actual path distros use (`bash: ./a.out: No such file or directory` on running executable produced by `ld`) – Peter Cordes Nov 13 '23 at 14:22
  • The ELF interpreter for a dynamically linked binary works very much like how the #! line works in a script. I think binfmt-misc also basically works this way, letting things like qemu work as an interpreter for binaries from a different architecture. – Peter Cordes Nov 13 '23 at 14:26
  • 1
    Everyone: please don't discuss the details of how this should work or whether it is a bug in the comments. If your comment is not asking for or providing a clarification to this answer, then please take it elsewhere. – terdon Nov 13 '23 at 14:27
  • @terdon: Yes, x86-64 chips have been sold by vendors other than AMD and Intel. The only one currently selling CPUs is Zhaoxin, according to https://en.wikipedia.org/wiki/List_of_x86_manufacturers . Past vendors include Centaur and Via (who sold their x86-64 division to Zhaoxin I think). And yes, I'm pretty sure all of these had x86-64 CPUs; the list of 32-bit x86 vendors is way longer; that wiki article unfortunately doesn't distinguish. TL:DR: you can take out "possibly" or replace with "a few others". – Peter Cordes Nov 13 '23 at 14:34