Definition
A fat binary (also called a universal binary or multi‑architecture binary) is a single executable file that contains compiled code for two or more processor architectures. When the operating system loads the program, it selects the appropriate architecture slice for the host CPU, allowing the same file to run on different hardware platforms without modification.
Historical Context
The term originated in the early 1990s with the rise of Macintosh computers that transitioned between PowerPC, 68 k, and later Intel processors. Apple introduced the concept as part of its Mach-O executable format, branding the files “Universal Binaries.” Similar practices later appeared in other environments, such as Linux’s ELF format supporting “fat ELF” files, and Windows’ PE format with “dual‑architecture” executables.
Technical Characteristics
| Aspect | Details |
|---|---|
| File format | Typically Mach-O on macOS, ELF on Linux, or PE on Windows. The format includes a container header that lists the contained architecture slices. |
| Architecture slices | Each slice is a complete, self‑contained binary for a specific CPU type (e.g., x86_64, arm64, i386, ppc). |
| Selection mechanism | The OS loader examines the header, matches the host CPU’s architecture, and loads the corresponding slice, ignoring the others. |
| Size implications | Fat binaries are larger than single‑architecture binaries because they store multiple copies of code and data. |
| Creation tools | macOS: lipo, xcodebuild with the -arch flag; Linux: llvm‑lipo or custom scripts; Windows: no standard tool, but developers may bundle separate executables in installers. |
Use Cases
- Cross‑generation support – Enables software distributors to provide a single download that works on both legacy and newer hardware (e.g., macOS apps supporting Intel and Apple Silicon).
- Simplified deployment – Reduces the need for separate installer packages per architecture, easing distribution and version control.
- Testing and development – Developers can ship test builds that run on diverse CI machines without rebuilding for each target.
Advantages
- User convenience – End users receive one executable that works regardless of their machine’s CPU.
- Version consistency – Guarantees that all users run the same version of the software, avoiding split‑version bugs.
Disadvantages
- Increased download size – Larger binaries can be problematic for bandwidth‑limited environments.
- Potential for outdated slices – If a slice is not rebuilt when the source code changes, the fat binary may contain a mixture of current and stale code.
Notable Examples
- Apple’s macOS “Universal 2” applications, which contain both Intel (
x86_64) and Apple Silicon (arm64) slices. - Early PowerPC/Intel transition binaries for macOS 10.4–10.5.
- Some open‑source projects (e.g., Homebrew formulae) provide universal binaries for macOS to support both architectures.
Related Concepts
- Multi‑arch Docker images – Containers that include layers for different CPU architectures, analogous to fat binaries at the container level.
- Cross‑compilation – Building separate binaries for each architecture, as opposed to bundling them together.
- Dynamic linking – An alternative to fat binaries where a single executable dynamically loads architecture‑specific libraries at runtime.
References
- Apple Developer Documentation, “Creating Universal Binaries.”
- Mach-O File Format Reference, Apple Inc., 2023.
- “ELF Handling For Multiple Architectures,” Linux Foundation, 2022.
- “PE (Portable Executable) Format,” Microsoft Docs, 2024.
This entry reflects current, verifiable information about the term “fat binary” as used in computing.
