You copy a dynamically linked binary that was built on Ubuntu onto an Alpine Linux machine. The file is present, owned correctly and executable, but running it prints `./server: not found`. Why does Alpine refuse to run it, and what are your options?

## The error message is lying to you `not found` from a shell almost always means the path you typed does not exist. When you have just `ls`-ed the file and it is plainly there, the message is reporting a *different* missing path: the one baked inside the executable. Understanding that single indirection is the whole question, and it is the most common first day on Alpine Linux. ## What PT_INTERP is A dynamically linked ELF executable cannot start on its own. It carries a program header of type `PT_INTERP` holding the absolute path of a helper program — the dynamic loader — whose job is to map the executable, load every shared library it needs, resolve symbols, and jump to the entry point. When you `execve` such a file, the kernel reads `PT_INTERP`, and if that path does not resolve, the whole `execve` fails with ENOENT. The shell has no way to tell you which of the two paths was missing, so it prints the one it knows. On a glibc x86-64 system that path is `/lib64/ld-linux-x86-64.so.2`. On Alpine it is `/lib/ld-musl-x86_64.so.1`. Neither libc installs the other's loader, so a glibc-built binary dropped onto Alpine is asking for a file that was never there. ``` readelf -l ./server | grep -A1 INTERP # [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] ``` `file ./server` prints the same information more compactly, and both tools work on any distribution, so you can run the check on either side. ## Why Alpine is different in the first place Alpine builds its entire userland against musl, a small, permissively licensed libc written for correctness and size rather than for glibc compatibility. musl is not a drop-in ABI clone of glibc: it does not implement glibc's symbol versioning, it omits or behaves differently in a number of GNU extensions, and it does not provide glibc's Name Service Switch plugin mechanism. That is a deliberate design position, and it is the source of essentially every Alpine surprise — this loader error is just the loudest one. ## Distinguish the two failure modes There are two different musl/glibc failures and candidates conflate them: 1. **The interpreter is missing.** `execve` never succeeds; you get a bare `not found` from the shell. This is the case above. 2. **The interpreter runs but a library is missing or a symbol is unresolved.** Here musl's loader *did* start and prints its own diagnostic, typically `Error loading shared library libfoo.so.1: No such file or directory` or an unresolved-symbol message naming the symbol. That is a dependency problem, not an ABI-selection problem. Knowing which one you have tells you whether you need a different build or just another `apk add`. ## The options, honestly ranked **Rebuild against musl.** The clean answer. Compile on Alpine, or cross-compile with a musl toolchain. For most compiled languages this is routine; for Go it is a build tag away; for Rust there is a musl target triple. This is the only option that leaves you with a first-class binary. **Link statically.** A fully static binary has no `PT_INTERP` at all, so the host libc is irrelevant. Go with `CGO_ENABLED=0` produces exactly this and runs unmodified on Alpine. Note the trap on the other side: a *glibc* program linked with `-static` is still not truly self-contained, because glibc's `getaddrinfo` and user lookups load NSS modules with `dlopen` at run time, and glibc warns about it at link time. **Install `gcompat`.** Alpine packages a compatibility layer that makes many glibc-linked binaries work on musl; the older `libc6-compat` package provides the loader path symlinks. This is the pragmatic escape hatch for a vendor binary you cannot rebuild, but it is a shim: anything reaching for glibc-specific behaviour, versioned symbols or NSS can still fail, and you have now built your production story on a translation layer. **Use a glibc distribution.** Sometimes the right answer, and saying so is a sign of judgment rather than defeat. The whole reason to be on Alpine is a small footprint; if you are going to spend a week fighting the libc, the footprint was not worth it. ## Why interviewers ask this It separates people who have shipped on Alpine from people who have read that it is small. The answer requires knowing that a libc is an ABI and not just a package, that ELF records an absolute loader path, and that a confusing error message can be about a file you never typed.