Зв'язок з динамічною бібліотекою із залежностями

Розглянемо такий сценарій:

• Спільна бібліотека libA.so, без залежностей.
• Спільна бібліотека libB.so, залежно від libA.so.

Я хочу скомпілювати двійковий файл, який зв'язується з libB. Чи слід пов'язувати двійковий файл лише з libB або з libA?

Чи є спосіб зв’язати лише прямі залежності, дозволяючи розв’язання невирішених символів із залежностей на час виконання?

Мене турбує той факт, що реалізація бібліотеки libB може змінитися в майбутньому, вводячи інші залежності (наприклад, libC, libD, libE). У мене будуть проблеми з цим?

Іншими словами:

• Файли libA: a.cpp ах
• Файли libB: b.cpp bh
• основні програмні файли: main.cpp

Звичайно, b.cpp включає ah, а main.cpp - bh

Команди компіляції:

g++ -fPIC a.cpp -c
g++ -shared -o libA.so a.o

g++ -fPIC b.cpp -c -I.
g++ -shared -o libB.so b.o -L. -lA

Який із наведених нижче варіантів слід використовувати?

g++ main.cpp -o main -I. -L. -lB

або

g++ main.cpp -o main -I. -L. -lB -lA

Я не міг використати перший варіант. Лінкер скаржиться на невирішені символи з бібліотеки libA. Але мені це звучить трохи дивно.

Дуже дякую.

- Оновлені коментарі:

Коли я зв'язую двійковий файл, компонувальник намагатиметься вирішити всі символи з основного та libB. Однак libB має невизначені символи з libA. Тому лінкер скаржиться на це.

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

g++ main.cpp -o main -I. -L. -lB -Wl,-unresolved-symbols=ignore-in-shared-libs

Схоже, все ще можна використовувати -rpath опцією. Однак мені потрібно це зрозуміти трохи краще.

Хтось знає можливі підводні камені при використанні -Wl,-unresolved-symbols=ignore-in-shared-libsопції?

- Оновлені коментарі 2:

-rpathне слід використовувати для цієї мети. Корисно змусити бібліотеку знаходитись у даному каталозі. -unresolved-symbolПідхід виглядає набагато краще.

Знову дякую.

Схоже, ви вже пройшли більшу частину шляху. Молодці з вашим розслідуванням. Давайте подивимось, чи можу я допомогти прояснити "чому", що стоїть за цим?

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

Однак він також виявляє, що деякі з цих символів використовують інші символи, які ще не вирішені у вашому виконуваному файлі, тому тепер потрібно вирішити і ці. Без посилання на libA.so ваша заявка буде неповною. Як тільки він зв'язується з libA.so, всі символи вирішуються, і зв'язування завершено.

Як ви бачили, використання -unresolved-symbols-in-shared-libs, не вирішує проблему. Він просто відкладає це так, що ці символи вирішуються під час виконання. Ось що-rpath : вказати бібліотеки для пошуку під час виконання. Якщо тоді ці символи неможливо вирішити, програма не зможе запуститися.

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

Тут є ще один опис цього процесу: чому порядок, у якому пов’язані бібліотеки, іноді спричиняє помилки в GCC?

Для динамічного зв’язування лише з прямими залежностями ви можете використовувати -Wl,--as-neededдодавання бібліотек після -Wl,--as-needed :

gcc main.c -o main -I. -L. -Wl,--as-needed -lB -lA

Для перевірки прямих залежностей вам слід використовувати readelf замість ldd, оскільки ldd також показує непрямі залежності.

$ readelf -d main | grep library
0x0000000000000001 (NEEDED)             Shared library: [libB.so]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

ldd також показує непрямі залежності:

$ LD_LIBRARY_PATH=. ldd ./main
linux-vdso.so.1 (0x00007fff13717000)
libB.so => ./libB.so (0x00007fb6738ed000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb6734ea000)
libA.so => ./libA.so (0x00007fb6732e8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb673af0000)

Якщо ви використовуєте cmake , ви можете додати наступні рядки, щоб включити лише прямі залежності:

set(CMAKE_EXE_LINKER_FLAGS    "-Wl,--as-needed ${CMAKE_EXE_LINKER_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--as-needed ${CMAKE_SHARED_LINKER_FLAGS}")

Інший варіант - використання libtool

Якщо ви зміните g++виклик libtool --mode=compile g++для компіляції вихідного коду , а потім libtool --mode=link g++для створення програми з libB, потім libAбудете пов'язані автоматично.

Це цікавий допис - я теж цим бився головою, але я думаю, ви тут пропустили момент ..

Ідея така, правда?

main.cpp =(depends)=> libB.so =(depends)=> libA.so

Давайте далі розглянемо, що ..

• У a.cpp (і лише там) ви визначаєте клас / змінну, назвемо це "symA"
• У b.cpp (і лише там) ви визначаєте клас / змінну, назвемо її "symB".
• symB використовує symA
• main.cpp використовує symB

Тепер libB.so та libA.so були скомпільовані, як ви описали вище. Після цього ваш перший варіант повинен запрацювати, тобто:

g++ main.cpp -o main -I. -L. -lB

Я думаю, ваша проблема походить від того, що

у main.cpp ви також посилаєтесь на symA

Я прав?

Якщо ви використовуєте символ у своєму коді, тоді цей символ потрібно знайти у файлі .so

Вся ідея взаємозв’язку спільних бібліотек (тобто створення API) полягає в тому, що символи в глибоких шарах приховані (подумайте про лущення цибулі) і не використовуються. .. тобто не посилайтеся на symA у вашому main.cpp, а лише на symB (і нехай symB посилається лише на symA).