Почему статическая ссылка больше не используется?

Я понимаю преимущества динамической компоновки (старый код может автоматически использовать возможности обновления библиотек, он более эффективен в пространстве), но он определенно имеет недостатки, особенно в гетерогенной экосистеме Linux. Это затрудняет распространение дистрибутивного агностического двоичного кода, который "просто работает", и делает ранее рабочую программу более вероятной для прерывания из-за системного обновления, которое нарушает обратную совместимость или вводит регрессии в общую библиотеку.

Учитывая эти недостатки, почему динамическая связь кажется настолько универсальной? Почему так сложно найти статически связанные дистрибутивные агностические Linux файлы, даже для небольших приложений?

Ответ 1

Существуют три большие причины:

GNU libc не поддерживает статическую привязку к себе, поскольку он широко использует dlopen. (Это означает, что статическая связь с чем-либо еще менее стоит, потому что вы не можете получить полностью статический двоичный файл без замены библиотеки C.)
Распределения не поддерживают статическую привязку к чему-либо еще, потому что это увеличивает объем работы, которую они должны выполнять, когда библиотека имеет уязвимость безопасности.
Распределения не имеют никакого интереса в дистрибутив-агностических двоичных файлах. Они хотят получить источник и сами создать его.

Вы также должны иметь в виду, что экология программного обеспечения Linux-not-Android полностью основана на исходных текстах. Если вы отправляете двоичные файлы, и вы не являетесь дистрибьютором, вы делаете это неправильно.

Ответ 2

Есть несколько причин, по которым мы предпочитаем динамическую связь:

Licensing. Это особая проблема с LGPL, хотя есть и другие лицензии с аналогичными ограничениями.

В принципе, для меня законно отправлять вам двоичный код, созданный против LGPL libfoo.so. *, и даже предоставить вам двоичный файл для этой библиотеки. У меня есть различные обязанности, такие как ответ на запросы источника для библиотеки LGPL'd, но главное здесь в том, что мне не нужно давать вам источник для моей программы. Поскольку glibc является LGPL, и почти каждый бинарный файл на Linux-боксе связан с ним, это само по себе приведет к динамической привязке по умолчанию.
Расходы на пропускную способность. Люди любят говорить, что пропускная способность бесплатна, но это верно только в принципе. Во многих практических случаях пропускная способность по-прежнему имеет значение.

Моя основная корпоративная система на базе С++ объединяется в RPM с пропускной способностью ~ 4 Мбайт, что занимает несколько минут для загрузки по медленным восходящим линиям DSL на большинстве сайтов наших клиентов. У нас по-прежнему есть некоторые клиенты, доступные только через модем, и для тех, кто загружает, это вопрос "начать его, а затем пойти на обед". Если бы мы отправляли статические двоичные файлы, эти пакеты были бы намного больше. Наша система состоит из нескольких взаимодействующих программ, большинство из которых связаны с одним и тем же набором динамических библиотек, поэтому RPM будет содержать избыточные копии одного и того же общего кода. Сжатие может выжать часть этого, но зачем им отправлять его снова и снова для каждого обновления?
Управление. Многие из библиотек, которые мы связываем, являются частью дистрибутива ОС, поэтому мы получаем бесплатные обновления для тех библиотек, которые не зависят от нашей программы. Нам не нужно управлять им.

Мы отдельно отправляем некоторые библиотеки, которые не являются частью ОС, но они должны меняться гораздо реже, чем это делает наш код. Как правило, они устанавливаются в системе, когда мы создаем сервер, а затем никогда не обновляемся снова. Это связано с тем, что нас чаще всего интересует стабильность, чем новые функции из этих библиотек. Пока они работают, мы их не трогаем.