On an empty base image, a binary that ran fine on the build host exits immediately — why?

## Why a binary needs the image to supply anything An executable can be built two ways. **Statically linked**, everything it needs is inside the file, and it will start on an empty filesystem. **Dynamically linked**, the file names the shared libraries it requires and defers them: every time it starts, something walks that list, finds each library on the filesystem, maps it in, and only then transfers control to the program's own entry point. That second arrangement is the default in most toolchains, because it saves space and lets libraries be patched without rebuilding every program that uses them. The cost is that the executable is **a contract with its surroundings**, and moving it into an image changes the surroundings completely. On the build host, the surroundings were a full userland with the libraries already present. Inside an empty base there is nothing, so the resolution step fails and the process dies **before its first line runs**. This is why there is no application log, no start-up banner, and often no useful message at all — the failure is upstream of everything the program would have printed. ## The two shapes of the failure | Shape | What you see | Why it happens | What fixes it | |---|---|---|---| | Libraries absent | Immediate exit, complaint about a missing loader or shared object | The empty base supplies nothing | Static link, or copy each named library in | | Libraries present but wrong | Immediate exit even though a library with that name exists | The base's library implementation family differs from the one the artifact was compiled against | Rebuild against the target base's family, or link statically | The second shape is the nastier one, because a check that only asks *is there a library with this name* answers yes. Library names are shared across implementations; their contents are not. ## Ruling it in before you build 1. **Ask the artifact what it needs.** Every toolchain can list an executable's dynamic dependencies. That list is the requirement set for the final image. 2. **Compare it with what the base supplies.** The difference is exactly what you must copy in — and if the difference is empty but it still will not start, you are in the second shape above. 3. **Start the final image in the pipeline.** Not the build stage, not the base: the image you are about to publish, exercised through one real code path. 4. **Do it before anything is pulled onto hundreds of hosts**, because the symptom on a fleet is an instant restart loop with nothing to read. ## The three fixes and what each costs - **Link statically.** Nothing is resolved at run time, so the empty base is genuinely viable. The cost is that a library fix now means rebuilding your artifact rather than replacing a file, and not every toolchain or dependency supports it. - **Copy the libraries in.** Straightforward and precise, and it works with any base. The cost is ownership: files you copied by hand have no publisher's stream behind them, so keeping them current is now yours. - **Match the base to the toolchain.** Build and run against the same library family, which removes the second shape entirely. The cost is that the base is now pinned to a build decision, and changing either means revalidating both. There is a fourth option people reach for and should not: installing the missing library inside the running container. On a minimal or empty base there is no package manager to do it with, and even where there is, the change dies with the container and never reaches the next replica. An image is fixed once built; the fix is always a rebuild. ## Why the same class of bug bites data files too A dynamically linked library is only the loudest member of a family of **run-time dependencies the base used to supply invisibly**. The others fail later and more quietly: - A trust store the client reads when it opens an encrypted connection. - Timezone and locale data read the first time an instant is formatted. - Configuration files some processes read rather than asking the platform. - Character-set tables, which corrupt output rather than raising an error. The library case fails at start-up, which is a gift: you find it in seconds. The data-file cases fail on the first request that touches the code path, possibly days later. Both have the same cause — a dependency that was always there and was never declared — and the same guard: exercise the final image, not the build environment. ## What the interviewer is checking That you know an executable is not automatically self-contained; that you can name the two shapes and tell them apart; that your fix is a rebuild rather than something applied to a running container; and that you catch it in the pipeline rather than in production. None of that depends on which platform is running the container, which is precisely why it gets asked.