💾 Archived View for bbs.geminispace.org › s › Linux › 5011 captured on 2024-07-09 at 04:40:52. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

binary file reported as 'no such file or directory' upon execution

This has to be the weirdest behavior ever.

A small utility that works fine on my main machine was copied over to my Thinkpad, running identical XUbuntu. Fails on ThinkPad only

I can ls it, permissions are fine, even HD and objdump look reasonable.

When I try to invoke it from command line, bash reports that it does not exist. strace shows execve with correct path, craps with ENOENT (no such file or directory)

It's like it doesn't exist, but only on execution. I cannot come up with a reasonable scenario.

Any thoughts?

Posted in: s/Linux

🚀 stack

2023-09-01 · 10 months ago

12 Comments ↓

🏕️ Captain · 2023-09-01 at 14:22:

how are you calling it? like "./utility" ? Is it marked as executable (chmod +x utility)?

🚀 stack [OP] · 2023-09-01 at 14:29:

Executable. Invoked every way, full path, etc. strace shows path!

🚀 IO · 2023-09-01 at 15:05:

Something like this happened to me before. In the end (in my case anyway) it turned out to be a binary for a different platform; arm on x64 or vice-versa. The error message wasn’t very helpful.

Edit: actually, that might have been an ELF error that time. I did have the same issue as you but I forget how I fixed it in the end.

🚀 stack [OP] · 2023-09-01 at 15:10:

OK, that is possible. It's a 32-bit binary... I remember something about Linux dropping 32bit support, requires installing some package. maybe libc because asm-built low-level binaries work fine (my nforth)

🚀 wat · 2023-09-01 at 15:27:

this is most likely caused by the binary using the wrong link loader /lib/ld.so.XYZ. one case of this is 32 bit binaries requiring a diferent one. Easy way to check, call file ./util to see its expecred path

🦀 jeang3nie · 2023-09-01 at 16:25:

I think wat is on the right track here. On Linux you get this error if the dynamic loader can't be found. This happens when you have a dynamically linked binary compiled against a different libc (glibc vs musl). It can also be down to the difference between 32 and 64 bit.

You can run 32 bit binaries on a 64 bit system provided you have the appropriate 32 bit runtime and libraries installed, which most distributions don't ship by default anymore because it massively increases the size of the distribution and is rarely used. That's why you have /lib32 and /lib64 directories instead of just /lib.

Whatever the cause, it's not exactly a helpful error. I've seen it trip a number of people up over the years, and the first time I saw it I did a bit of head scratching myself.

🚀 stack [OP] · 2023-09-01 at 16:43:

Geez... You'd think a mature distro bigger than a gigabyte would report basic errors sensibly. Like "missing 32-bit support"

🐙 norayr · 2023-09-01 at 18:16:

can you run file utility and give it your binary?

like:

file ./yourbinary

and also do

file /bin/bash

and paste here.

🚀 stack [OP] · 2023-09-01 at 19:13:

./fasmlist: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, 
interpreter /lib/ld-linux.so.2, BuildID[sha1]=d85decb81a47920afb2e52c6215debdceaea3dfe,
 for GNU/Linux 3.2.0, not stripped

🐙 norayr · 2023-09-01 at 23:14:

and what is the output of

file /bin/bash

or some other binary that runs?

also can you do ldd on both - the file that doesn't run and something that does?

🚀 stack [OP] · 2023-09-02 at 01:05:

I won't be able till tomorrow.

😈 dimkr · 2023-09-02 at 08:44:

dpkg --add-architecture i386 && apt update && apt install libc6:i386 should fix this, if this is Debian or a derivative like Ubuntu. This is the error you get when you run a 32-bit executable on a 64-bit OS but the 32-bit loader (part of glibc) is missing.