Чи насунуті статичні бібліотеки? [зачинено]

Є два аргументи для спільного використання бібліотек:

1. Це сприяє зменшенню місця на диску.
2. Коли оновлена ​​бібліотека оновлюється, всі бінарні файли залежно від неї отримують оновлення.

В основному є один недолік спільних бібліотек:

• Вони (можуть) ввести залежність пекла.

На настільних комп’ютерах перша перевага насправді вже не є. Втрата часу на диску не є великою проблемою в ці дні.

Наявність статичних двійкових файлів дозволило б нам покращити менеджерів пакетів - я маю на увазі, пекло залежностей було б минулим. Додавання програми було б просто додаванням двійкового файлу; врешті-решт папка, щоб вона обробляла свої файли. Видалити програму було б просто видалити цей файл. Залежності? Пропав.

Друга перевага все ще залишається, але я думаю, що перевага статичних двійкових файлів на настільних комп’ютерах переважає її. Я маю на увазі, що навіть нові мови, як-от Go, збирають усі свої двійкові файли, незважаючи на переваги спільних бібліотек, через зручність.

Оскільки одна з головних переваг бібліотек, що поділяються, вже не є великою справою, чи статичні бібліотеки С все ще нахмурені? Якщо так, то чому?

Передумова вашого запитання хибна. Те, що нахмуриться, дотримується доктринальних і абсолютних без розуміння основи, що стоїть за ними (Cargo Cult Programming?).

Пов'язана відповідь ТА є цікавим дослідженням у цій самій темі. Питання стосувалося того, чому компіляція із -статичним варіантом не працює, відповідь, на яку ви посилаєтесь, була не що інше, як скандал про використання статичного посилання. Якщо не обговорюється, чому це погано, і вимагає, щоб ОП використовує динамічні зв'язки. Прикро, що вона позначена як правильна відповідь (наступна відповідь має вдвічі більше голосів і є правильною відповіддю на питання ОП), оскільки, хоча правильна відповідь є, її глибоко приховано серед догматичної думки.

Справжнє питання полягає у тому, які плюси та мінуси статичного та динамічного зв’язування та коли можна віддати перевагу іншим.

З точки зору розробника, динамічне посилання часто може значно прискорити компіляцію / посилання / тестовий цикл.

Наприклад, з точки зору управління пакетами, візьміть, наприклад, libGL. У мене в диспетчері пакунків доступно близько десятка різних його реалізацій, деякі загальні та деякі націлені на певні графічні карти. Якби це не було динамічно пов'язане, у кожної програми, що посилається на libGL, повинно бути десяток версій, інакше вам доведеться розробити додатковий рівень абстракції, який не такий ефективний, як виклик функції.

Подумайте про питання безпеки в такій популярній бібліотеці, як Qt. За допомогою динамічного посилання я можу просто оновити цей один пакет, замість того, щоб ідентифікувати, перекомпілювати та розгортати кожен пакет, який посилається у Qt.

Статичне зв’язування може мати переваги в незалежно розгорнутих програмах із закритим кодом, але в управлінні пакетами з відкритим кодом це шкодить більше, ніж допомагає.

Менеджери дистрибуції Linux в основному надають перевагу спільним бібліотекам з точки зору вашої причини №2. Для них дуже важливо, що, наприклад, коли хтось виявить помилку безпеки в zlib , їм не доведеться перекомпілювати кожну програму, яка використовує zlib --- не тільки це коштуватиме їм більше циклів процесора, щоб зробити Після перекомпіляції кожен, хто використовує дистрибутив, повинен буде знову завантажити всі ці програми. Тим часом, у наборі пакетів, наданих дистрибутивом, пекло залежності не є проблемою, оскільки все тестується для роботи з цим набором бібліотек.

Якщо ви створюєте стороннє програмне забезпечення, яке потребує бібліотек, які не є у вашому розповсюдженні, то статично пов’язувати ці бібліотеки може бути менше клопоту, ніж альтернатива, і це добре.

Інша важлива річ, яку потрібно знати, це те libc, що libstdc++обидва GNU та GCC мають компоненти, які не працюють надійно, якщо бібліотека є стаціонарно пов'язаною. Найпоширеніша проблема полягає в dlopenтому, що будь-який модуль, який ви завантажуєте dlopen, сам по собі динамічно пов'язаний libc.so.6. Отже, це означає, що у вас є дві копії бібліотеки С у своєму адресному просторі, і веселість виникає тоді, коли вони не погоджуються, яка копія внутрішньої mallocструктури даних (наприклад) є авторитетною. Це стає гірше: ціла купа функцій, які, здається, не мають нічого спільного dlopen, як gethostbynameі з iconvвикористаннямdlopenвнутрішньо (щоб їх поведінку було налаштовано під час виконання). На щастя, ABI для libc та libstdc ++ дуже стабільний, тому навряд чи ви зіткнетеся з проблемами, що їх динамічно пов'язують.

Я погоджуюся з останнім моментом mattnz: це питання є завантаженим питанням. Це передбачає, що статичні зв'язки є поганими. Я можу придумати дві причини, чому це не так:

• Статичне посилання є безпечним: якщо спільна бібліотека буде оновлена ​​таким чином, що програма використовує нову (можливо, нова перезаписала стару, або стару видалили), вона може ввести ризик, що нова версія зламає додаток. Це зміна коду за межами офіційного оновлення програми. Можливо, його не перевіряли. Статичне посилання пов’язує це, не обмінюючись бібліотеками зовні. Я вважаю, що це недолік для спільних бібліотек через цей ризик. Що робити, якщо нова версія спільної бібліотеки вводить нову помилку, яка порушує деякі старі програми?

• Статичне посилання забезпечує додатки більш автономними. Хоча спільні бібліотеки можуть бути розміщені з основним виконуваним файлом, вони часто зберігаються у спільних місцях. Статично пов’язані програми легше забезпечити "портативний" у значенні "не вимагає змін у файлах, каталогах чи налаштуваннях, що належать ОС" (думаю, що каталог, реєстр Windows тощо).

Статичні та динамічні бібліотеки мають власні потреби. Дивлячись на одну програму за обсягом, ми отримуємо інше уявлення про те, що потрібно, а що ні.

Статичне посилання різко спрощує розгортання програми. Не потрібно виявляти та мати справу з різними версіями. Просто запікайте і розгортайте.

Очевидною перевагою динамічних бібліотек є можливість самостійного застосування оновлень.

Це одна з причин, що я ненавиджу Maven та інших подібних розробників динамічних зв'язків для Java. Вони очікують, що єдиний варіант бібліотеки буде доступний за вказаною URL-адресою назавжди і назавжди. Не розуміючи проблеми, яка виникає через 10 років, коли ніхто не може скласти заявку, оскільки все джерело та банки вже немає.