Если вы создаете исполняемый файл, который работает в текущей версии Windows, этот исполняемый файл, вероятно, будет работать в течение многих лет в более новых версиях Windows. Microsoft прилагает все усилия, чтобы обеспечить это.
В Linux ожидается, что у вас будет исходный код используемого вами программного обеспечения, и поэтому нарушение двоичной совместимости допустимо, пока вы поддерживаете совместимость исходного кода. Это приводит к тому, что дистрибутивы постепенно отказываются от старых версий библиотек и периодически ломают то, что раньше работало.
Для того, кто использует Linux в качестве игровой платформы, это проблема, поскольку игры, как правило, распространяются только в двоичной форме. Это заставляет порты Linux выглядеть плохо, когда они ломаются, но у меня есть чувство, что было бы более продуктивно попытаться решить эту проблему в целом, а не ожидать, что все обновят свои порты.
Существуют ли дистрибутивы, которые пытаются сохранить двоичную совместимость, не обязательно сохраняя все старые версии, но, по крайней мере, сохраняя старые sonames, так что двоичный файл, работающий с выпуском n, должен также работать с выпуском n+1?
Самое близкое, что мне удалось найти, — это «Steam Runtime» от Valve, представляющий собой двоичный слой совместимости, доступный только для программ, распространяемых через Steam.
решение1
По сути, это сводится к следующему:вы не можете сохранить двоичную совместимость и ввести новые функции, поскольку эти вещи идут прямо друг против друга в большинстве аспектов. Если вы вводите новые крупные функции, вы в конце концовпридетсяизменить ABI (обычно вскоре после изменений в API). Теперь вы можете иметь версионные символы (как, например, Glibc), но это увеличивает размер библиотек (и может также повлечь за собой некоторое падение производительности при загрузке двоичного файла в память), и разработчики определенно не хотят хранить его в общих библиотеках (унаследованный код содержит ошибки, которые никто не хочет исправлять).
Обычный способ обойти эту проблему со стороны дистрибуции — два:
не меняйте версии — это характерно для дистрибутивов Enterprise-класса, таких как (в алфавитном порядке) RedHat и SUSE, а также для некоторых других (Debian, Slackware, Ubunty LTS и, вероятно, их клонов).
разрешить установку различных версий библиотеки одновременно.
В дистрибутиве приложений это делается так же, как и в Windows: все необходимое помещается в дистрибутив. Да, именно так часто делают в Windows — это также одна из причин, по которой типичная система Windows обычно имеет в несколько раз более высокие требования к дисковому пространству, чем Linux с той же функциональностью — приложения просто делятся между собой очень мало и имеют где-то свои собственные копии. Вы можете думать об этом как о каждом приложении GTK/Qt, поставляемом со своим собственным стеком GTK/Qt. Это может иметь некоторые преимущества, но недостатков также предостаточно. Например, с точки зрения безопасности это кошмар в Technicolor TM . Если двоичные файлы статически связаны, это даже в FullHD.