Why a binary says "not found" on Alpine Linux

The file is there and it is executable, yet Alpine says it cannot be found. The missing file is usually not your binary. It is the glibc loader your binary asks for.

/app # ls -l mytool
-rwxr-xr-x    1 root     root       4120344 mytool
/app # ./mytool
sh: ./mytool: not found

Why it happens

Most Linux distributions use the glibc C library. Alpine uses musl. A dynamically linked glibc binary names a loader such as /lib64/ld-linux-x86-64.so.2. That path does not exist on a standard Alpine system, so the kernel cannot start the program and the shell reports "not found".

Confirm the cause

readelf -l ./mytool | grep interpreter

If the output names ld-linux, the binary was built for glibc. A musl binary names /lib/ld-musl-x86_64.so.1 or, if it is static, shows no interpreter.

How to fix it

1. Publish a musl build. In Rust, build for x86_64-unknown-linux-musl. In C, build inside an Alpine container.
2. Build Go without cgo. CGO_ENABLED=0 go build gives a static binary that runs on both glibc and musl systems, if your code does not need cgo.
3. Use a glibc base image. If it is your own container and size is not critical, debian:12-slim avoids the problem.
4. Try gcompat as a stopgap. apk add gcompat provides a compatibility layer. It works for some programs, not all, so test it and do not treat it as a guarantee.