The Linux Standard Base addressed a practical problem: software built for one Linux environment could encounter different libraries, interfaces, or system conventions in another. That compatibility problem remains useful to understand even when an application is delivered through distribution packages or containers.
“Runs on Linux” is an incomplete requirement. A useful support statement names the processor architecture, distribution and release, runtime dependencies, and relevant hardware or service interfaces. Diagnose the missing layer before changing system libraries.
What LSB tried to standardize
The Linux Foundation's LSB specifications document common interfaces and architecture-specific requirements, including executable formats, libraries, commands, and system conventions across editions and modules. The archive includes LSB 5.0 as well as earlier specifications. Use the exact edition and architecture when interpreting a historical LSB claim.
An application binary interface, or ABI, describes details needed for already-compiled components to work together: calling conventions, binary formats, symbol interfaces, and related rules. A source-level API describes how code is written against an interface. Source compatibility does not guarantee that one compiled file runs unchanged everywhere.
LSB is not a universal promise that every Linux package or application is interchangeable. Nor does the presence of a command such as lsb_release prove that a machine conforms to an entire LSB specification. For a current deployment, the application's documented support matrix and the target distribution's maintained packages are more actionable than a generic compatibility label.
Check the boundary that can actually fail
On a small screen, scroll the table sideways to read all columns.
| Layer | Question | Example of a mismatch |
|---|---|---|
| Architecture and instructions | Was the executable built for this CPU and instruction set? | An ARM64 binary on an x86-64 host, or an x86 binary requiring newer CPU features. |
| Executable interpreter | Does the required program loader exist at the recorded path? | An ELF file requesting a loader absent from the target filesystem. |
| Libraries and symbol versions | Are the required ABI versions available? | A binary requesting a GLIBC symbol version the installed libc does not provide. |
| Runtime and application data | Do language runtime, modules, plugins and file formats match? | A supported executable loading an incompatible plugin or configuration. |
| Kernel and devices | Does the host provide the required system calls, drivers and interfaces? | A packaged application needing a device or kernel facility unavailable on the host. |
A newer-looking kernel cannot fix every userspace library mismatch. A copied library may itself depend on other libraries or a particular loader. Diagnose the complete chain instead of replacing one filename at a time.
Inspect before trying to execute
Confirm the download's source and integrity first. For a local ELF executable named ./program, the following commands gather host and binary information. They do not launch the target program:
uname -m
cat /etc/os-release
file ./program
readelf -h ./program
readelf -l ./program
readelf -d ./program
readelf --version-info ./programfile identifies the format; readelf -h shows the ELF header and machine type. Program headers from -l can identify the requested interpreter. The dynamic section from -d lists direct dependencies and relevant search-path entries; --version-info exposes symbol-version metadata. The GNU readelf manual documents these views. Some binaries are static or are not ELF files, so absence of a dynamic section needs interpretation.
These inspection tools parse the file without deliberately running it, but they are not a sandbox. Handle suspicious files in an appropriately isolated environment with maintained tools. In particular, the ldd manual cautions against using ldd on untrusted executables because some circumstances can lead to code execution. For trusted installed software, ldd can help show resolved dependencies, but it does not establish overall application compatibility.
On a glibc-based system, getconf GNU_LIBC_VERSION reports the libc version. It is not a universal command for every libc implementation. Match findings with the package manager and vendor requirements; avoid treating a single version string as a complete dependency report.
Read the error as evidence about a layer
“No such file or directory,” although the file exists: inspect the requested ELF loader or, for a script, its interpreter line. The missing object may be the interpreter rather than the visible file. Also confirm the exact path and environment. Creating an arbitrary loader symlink can turn a clear missing-file error into a harder ABI failure.
“GLIBC_… not found”: the program or one of its dependencies requires a symbol version that the loaded library does not supply. Prefer a build intended for the target distribution, a supported environment upgrade, or an appropriate isolated userspace. Replacing the distribution's libc manually risks breaking package tools and essential services.
“Exec format error” or “Illegal instruction”: check file format, architecture, and CPU feature requirements. These messages have multiple possible causes; the first does not always mean the wrong CPU, and the second is not proof of one particular extension mismatch. Keep the exact error, binary source, host details, and reproduction steps together.
A missing shared library: identify the package that supplies the required ABI in the target distribution. Similar names or a matching suffix are not enough. Do not download an unexplained library from a random site or redirect a dependency to an incompatible major version.
Choose a supportable remedy and verify the workload
First look for the application's maintained package for the exact target, or build from supported source using the intended toolchain. Preserve dependency records and test meaningful tasks, not only --version. A program can start and still fail when it loads a plugin, opens a database, or uses a graphics driver.
A container can package a matching userspace, but it does not contain an independent kernel in the same sense as a virtual machine. Docker's container explanation describes the shared-kernel model. Host architecture, kernel facilities, device access, and runtime configuration still matter; desktop container systems may provide that Linux kernel through a VM.
Fictional diagnosis: a vendor binary exists on a server but cannot find its recorded interpreter. Inspection shows that it targets a different userspace family. The administrator obtains the vendor's supported build for that server instead of inventing a loader symlink. The acceptance test covers its real import and export operations as well as startup.
Download the Linux compatibility diagnostic record (plain text). Use it to give a maintainer the binary identity, host details, relevant metadata, exact failure, and a verified remedy.