Где 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
Источник

2 ответа

Решение

Весь этот путь бизнеса связан с тем, что называется многоархитектурой. По сути, это позволяет вам иметь 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.
Источник

Информация, содержащаяся в вышеупомянутом вопросе И первый (и только ATT) ответ, помогла мне решить * похожую * проблему моего на WSL Ubuntu (на Win10 64)!

В моем случае исполняемый файл не может найти библиотеку. В конечном итоге я заметил, что недавно созданная библиотека оказалась в /usr/lib64, но многоарочные линии /etc/ld.so.conf.d/x86_64-linux-gnu.conf не включал этот каталог.

Итак, я побежал

sudo ldconfig /usr/lib64

и это наконец исправило это. (запуск его без параметра каталога не позволил "волшебным образом" найти библиотеки, кстати.) Неясно, помог ли "перезапуск" моего WSL bash... Я думаю, что это даже не нужно.

Источник
Другие вопросы по тегам