binarycompatibility

Binary compatibility refers to the ability of a compiled program to interface with another compiled artifact, such as a library or runtime, without requiring recompilation. It is largely about the application binary interface (ABI), including how functions are called, how data is laid out in memory, and how symbols are resolved at runtime. Binary compatibility is distinct from source compatibility, which concerns whether code would compile against a given API.

Maintaining binary compatibility requires that changes to a library or runtime do not alter the ABI in ways that would break existing binaries. This means preserving function names and calling conventions, the size and layout of data types, alignment and padding, endianness, and global symbol visibility. Practices to support compatibility include stable ABIs, versioned symbols, and careful deprecation rather than removal of features. Many systems also rely on dynamic linking and shared libraries to enable multiple components to be updated independently, provided their ABIs remain compatible.

Contexts where binary compatibility matters include operating-system platforms and languages that produce native binaries. In C and C++, developers often aim for ABI stability across minor releases, while changes that affect the ABI can force recompilation of dependent software. Examples of ABIs and conventions that influence binary compatibility include the System V AMD64 ABI and Windows x64 calling conventions. Other ecosystems, such as Java and .NET, handle compatibility through different mechanisms (bytecode or metadata compatibility) rather than native ABIs.

Practical approaches to preserve compatibility include designing stable interfaces, providing wrappers or shims when needed, and using explicit versioning and migration guides. When compatibility cannot be maintained, clear communication and tooling are used to manage transitions.