Стабильность ABI
- title
- Стабильность ABI
- type
- concept
- summary
- Контракты совместимости на уровне бинарного кода: философии ядра и glibc, Wine как стабильный вариант
- tags
- linux, abi, systems-programming
- created
- 2026-04-08
- updated
- 2026-04-08
- lang
- ru
- translation_of
- abi-stability
- source_updated
- 2026-04-08
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
ABI (Application Binary Interface) - это контракт на уровне бинарного кода между скомпилированной программой и системой, в которой она работает: соглашения о вызовах, раскладка структур в памяти, разрешение символов, номера системных вызовов. Совместимость по API на уровне исходного кода означает, что код собирается; совместимость по ABI гарантирует, что уже скомпилированный бинарник продолжает работать.
Поломки ABI куда неприятнее поломок API. Отсутствующую сигнатуру функции поймает компилятор. Нарушенный ABI приводит к segfault'ам, тихому повреждению данных или библиотекам, которые загружаются, но ведут себя некорректно. Пользователи сталкиваются с падениями без видимых причин, а разработчики не могут воспроизвести проблему, потому что на их системе установлена правильная версия библиотеки.
Две философии в Linux
Ядро Linux и glibc придерживаются противоположных взглядов на этот вопрос.
Ядро относится к ABI как к практически абсолютному контракту. Правило Линуса Торвальдса: если изменение ломает userspace и кто-то это заметил, это регрессия, точка. Не имеет значения, было ли старое поведение багом или вообще не было задокументировано. Если реальный софт от него зависит, теперь это часть ABI. Эта политика соблюдается неукоснительно - Торвальдс откатывал изменения в ядре, ломавшие рабочий процесс даже одного-единственного пользователя.
Glibc исповедует буквоедский подход к спецификациям. Если что-то не задокументировано как часть ABI, разработчики glibc вправе это изменить, а проблемы в софте, который зависел от прежнего поведения, остаются проблемами этого софта. Хрестоматийный пример - удаление DT_HASH в glibc 2.36: DT_HASH входил в generic ABI SYSV, но в glibc заявили, что это не часть их ABI (поскольку используется ELFOSABI_GNU), и выкинули его, несмотря на то, что это сломало реальные приложения.
Гарантии стабильности Wine
Wine сохраняет ABI-совместимость с Win32 на протяжении десятилетий. Бинарник для Windows из 2003 года должен нормально запуститься. Парадоксальным образом это делает Wine более стабильной платформой для игр на Linux, чем сам нативный Linux. Нестабильность исходит от слоя glibc, а не от ядра - со стороны ядра всё надёжно как скала.
Наблюдение "Win32 - единственный стабильный ABI в Linux" как раз отражает этот разрыв: ядро обещает стабильность, Wine обещает стабильность, а находящаяся между ними библиотека Си - нет.
Почему это важно
Стабильность ABI позволяет выпустить бинарник и быть уверенным, что он продолжит работать через пять лет без перекомпиляции. Платформы, которые её обеспечивают (Windows, в определённой степени macOS, интерфейс системных вызовов ядра Linux), получают долгоживущий сторонний софт. Платформы, которые этого не делают (внутренние интерфейсы glibc, многие интерфейсы динамических библиотек Linux), подталкивают разработчиков к статической линковке, контейнерам или вовсе к выбору другой целевой платформы.