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

Question

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

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

Answer 1

Есть три основные причины:

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

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

Answer 2

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

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

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

2. Пропускная способность стоит .Люди любят говорить, что пропускная способность бесплатна, но это верно только в принципе.Во многих практических случаях пропускная способность по-прежнему имеет значение.

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

3. Управление .Многие библиотеки, на которые мы ссылаемся, являются частью дистрибутива ОС, поэтому мы получаем бесплатные обновления этих библиотек независимо от нашей программы.Нам не нужно управлять этим.

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