Де Ubuntu шукає спільні бібліотеки?

Коли я запускаю процес, який посилається на спільну бібліотеку під час виконання (пов'язаний, коли процес починається, не пов’язаний пізніше dlload()), де він шукає .soінший файл спільної бібліотеки ( ) LD_LIBRARY_PATH?

Фон:

У мене є якийсь код C ++, який я написав, який використовує певну сторонній бібліотеку. Я встановив бібліотеку і скомпілював свій код на двох різних платформах, як Ubuntu, але різні версії, так і різні версії gcc. Бібліотека була зібрана та встановлена з джерела та розташована /usr/local/libна обох платформах. Коли я компілюю свій код, я пов'язую з pkg-config --libsпараметрами для сторонньої бібліотеки, і я перевірив, що pkg-config --libsповертає точно те саме на обох платформах.

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

error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory

Як не дивно, тим, що не працює, є новіша версія Ubuntu та gcc. : /

Тому я намагаюся розібратися, як робоча здатна знаходити бібліотеку, щоб я міг змусити зламану знайти бібліотеку таким же чином. (тобто без налаштування LD_LIBRARY_PATH)

Оновлення:

Ось мій вихід із cat /etc/ld.so.conf.d/*

... про працюючу (старшу) систему:

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

... про порушену (новішу) систему:

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa

libraries shared-library dynamic-linking

— Дейв Ліллетун
джерело

Я думаю, що ці місця визначені /etc/ld.so.conf.d/*.conf, але я не впевнений у цьому.

— Салем

Це здається, але дивіться моє оновлення до OQ щодо вмісту цих файлів ... Так виглядає, що його слід знайти, /usr/local/lib/libthrift-0.9.0.soале все-таки він видає помилку error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... Чи є причина, з якої він не підбиратиме каталог /etc/ld.so.conf.d/*.conf?

— Дейв Ліллетун

Спробуйте запустити, sudo ldconfig -vяк запропоновано нижче. Якщо це все ще не працює, оновіть своє запитання на виході ldd /path/to/your/application.

— Салем

Відповіді:

Весь цей шлях бізнесу пов’язаний із чимось, що називається багатосхилим. В основному це дозволяє вам мати 32-бітні та 64-бітні бібліотеки в одній системі.

Після того як ви скопіювали файл, чи траплялось вам запустити ldconfig?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.

— Метт Н
джерело

Я побіг sudo ldconfigі це вирішило проблему! (Не потрібно було перекомпілювати свій код чи що-небудь таке ...) Хоча я просто хочу зрозуміти ... Ви сказали "Після того, як ви скопіювали файл", але я не скопіював файл. Ви маєте на увазі після того, як я створив і встановив бібліотеку або після того, як склав програму?

— Дейв Ліллетун

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

— Метт H

Можливо, я помиляюся, але я вважаю, що перезавантажився з моменту встановлення бібліотеки ... Проте sudo ldconfigзробив трюк. Це щось, що бібліотеки часто автоматично запускаються для вас у рамках їх установки, а ця чомусь не сталася? Цікаво, чому я "нормально" цього не маю робити, а робив лише в цьому випадку ...

— Дейв Ліллетун,

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

— Метт H

Інформація, що міститься у вищезазначеному питанні І перша (і лише ATT) відповідь , допомогла мені вирішити * подібний * мій випуск у WSL Ubuntu (на Win10 64)!

У моєму випадку виконуваний файл не міг знайти бібліотеку. Я в кінці кінців зауважив , що новоспечена бібліотека отримала розташований в /usr/lib64, але в декількох арочних лініях /etc/ld.so.conf.d/x86_64-linux-gnu.conf навіть НЕ включають в цей каталог.

Тому я побіг

sudo ldconfig /usr/lib64

і це остаточно виправило. (запуск його самостійно без параметра каталогу не змусив його "чарівно" знаходити бібліотеки BTW.) Незрозуміло, чи допоміг "перезапуск" мого WSL башу ... Я думаю, це навіть не було потрібно.

— Йордан Джи
джерело

Те саме сталося зі мною з / usr / local / lib /. Я створив файл, /etc/ld.so.conf.d/usr-local.confа потім запустив sudo ldconfigбез ефекту - завантажувач не знайшов бібліотеки в цьому режимі. Після запуску sudo ldconfig /usr/local/libвсе працювало чудово.

— Джош Мільторп