Чому системи Unix / Linux не проходять через каталоги, поки не знайдуть потрібну версію зв'язаної бібліотеки?

У мене є двійковий виконуваний файл з назвою "альфа", для якого потрібна пов'язана бібліотека (libz.so.1.2.7), яка розміщується в /home/username/myproduct/lib/libz.so.1.2.7

Я експортую те ж саме до свого термінального екземпляра, перш ніж нерестувати свій бінарний виконуваний файл, виконавши наступну команду.

export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH

Тепер, коли я нерестую ще одну програму "bravo", яка вимагає тієї ж бібліотеки, але різної версії, тобто (libz.so.1.2.8), яка доступна в /lib/x86_64-linux-gnu/libz.so.1.2.8, система видає наступну помилку.

version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)

Якщо я скасую LD_LIBRARY_PATH, "bravo" починає чудово. Я розумію, що вищезгадана поведінка полягає в тому, що вона LD_LIBRARY_PATHмає перевагу над шляхами до каталогу, визначеними в /etc/ld.so.confпроцесі пошуку зв’язаних бібліотек, і, отже, вищезгадана помилка. Мені просто цікаво, чому розробники UNIX / LINUX не створили ОС для пошуку пов'язаних бібліотек в інших каталогах відповідно до ієрархії, якщо перший екземпляр бібліотеки має іншу версію.

Простіше кажучи, системи UNIX / LINUX проходять через набір каталогів, поки не знайдуть потрібну бібліотеку. Але чому він не робить те саме, доки не знайде очікувану версію, а не приймає перший екземпляр бібліотеки незалежно від її версії?

— daedalus_hamlet
джерело

Я не зовсім впевнений, але я б здогадувався про безпеку. Мені особисто не хотілося б турбуватися про сим-зв'язок де-небудь на моїх машинах

— Джо

@Joe Багато хто з самих бібліотек мають посилання на них. libz.so.1є символьним посиланням наlibz.so.1.2.8

— Nasir Riley

Але чому він не робить те саме, доки не знайде очікувану версію, а не приймає перший екземпляр бібліотеки незалежно від її версії?

Це робить, наскільки це відомо. zlib.so.1.2.7і в zlib.so.1.2.8обох є прізвище zlib.so.1, тому ваш alphaі bravoдвійкові файли кажуть, що вони потрібні zlib.so.1. Динамічний завантажувач завантажує першу відповідну бібліотеку, яку він знайде; не знає, що версія 1.2.8 надає додаткові символи, які bravoпотребують. (Ось чому розповсюдження не потребує уточнення додаткової інформації про залежність, наприклад zlib1g (>= 1.2.8)для bravo.)

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

Деякі бібліотеки надають інформацію про версії, яка в кінцевому підсумку зберігається в ній .gnu.version_rіз посиланням на бібліотеку, що допоможе тут, але libzце не одна з них.

(Враховуючи імена, я б очікував, що ваш alphaдвійковий файл буде добре працювати zlib.so.1.2.8.)

— Стівен Кітт
джерело

І слід також зазначити, що версія бібліотеки у стилі GNU відрізняється від семантичної (-ish) версії, до якої ми найбільше звикли. Оскільки вони мають однакове "поточне" число 1, zlib.so.1.2.8 не повинен надавати жодних функцій, яких zlib.so.1.2.7 не має, отже, це не повинно мати значення (з точки зору ABI), яке саме знайдено. Що це має значення, слід вважати недоліком.

— Джон Боллінгер

@John ні, єдина гарантія полягає в тому, що бібліотеки з тим самим іменем є сумісними назад; нові бібліотеки можуть додавати функції, вони не можуть видалити будь-які або змінити їх невідповідним способом. Тобто, двійковий файл, побудований проти zlib 1.2.7, буде працювати з тим або будь-яким новим zlib 1; але двійковий файл, побудований проти zlib 1.2.8, не обов'язково буде працювати зі старішим zlib 1. (І семантичне версії дозволяє це; але обробка імен не семантична версія.)

— Стівен Кітт,

Як я вже говорив, я конкретно говорю про конвенції GNU, і, мабуть, думаю про libtool . Не кожен проект дотримується цієї конвенції, тому, мабуть, це занадто сильно, щоб назвати недоліком zlib, але з іншого боку, навіть семантико-версійне тлумачення номерів версій бібліотеки прийшло б до такого ж висновку. Сумісність вперед (бінарна) у таких випадках не є обіцянкою, властивою імені, але в цьому випадку є розумним очікуванням.

— Джон Боллінгер

Так, я добре розумію взаємозв'язок між номерами CRA та SOVERSION, що повертається до мого початкового моменту: ситуація, описана ОП, здається, не відповідає правильному використанню схеми CRA . Уникнення таких проблем, як ОП, є однією з ключових цілей цієї схеми. Якщо zlib додає новий (версія a) бінарний інтерфейс, його число C слід збільшити. Це може призвести до того, що такий удар також може призвести до перешкод, пов'язаних з реверсією.

— Джон Боллінгер

@John right, я підозрюю, що ми досягли жорстокої згоди і що я неправильно зрозумів точку, яку ви домовились. zlibні в libtoolякому разі не використовує , за винятком Дарвіна, де це ar;-).

— Стівен Кітт