Understanding ld64 Static Linking on iOS: Architecture, Symbols, and Optimizations

The article begins with an overview of static linking, describing how ld64 processes .o, .a, and .dylib files to generate an executable, and highlights its role in iOS builds.

It then details fundamental concepts: object files contain symbols and sections; static libraries (.a) store symbol tables mapping names to .o offsets; dynamic libraries (.dylib) and text‑based stubs (.tbd) provide export information used during linking.

Key sections explain symbol types (global, local, undefined), visibility, strong/weak definitions, tentative definitions, and relocation entries, illustrating how ld64 parses these structures.

The command‑line processing stage converts arguments into input file paths and option flags, while the parsing stage reads headers, load commands, and builds atom and fixup structures for each file.

During the resolving phase, ld64 builds a global SymbolTable, merges atoms, resolves undefined symbols by searching static and dynamic libraries, creates proxy atoms for dynamic symbols, and handles special cases like section boundaries and tentative symbols.

Dead‑code stripping uses an atom graph to identify live atoms from root symbols (entry point, forced loads, exported symbols) and removes unused atoms, followed by coalescing and internal state organization.

Multiple passes (e.g., ObjC handling, stub generation, deduplication) are applied to optimize the output, after which ld64 generates the final Mach‑O file, symbol table, and link‑edit information.

Additional topics cover auto‑linking via LC_LINKER_OPTION, the -ObjC flag for loading Objective‑C categories, debugging options such as -print_statistics, -t, -why_load, -why_live, and -map, as well as support for Link‑Time Optimization (LTO) using libLTO.

The article concludes with references to Apple’s open‑source ld64 repository and related documentation.