Где Ubuntu ищет общие библиотеки?
Когда я выполняю процесс, который связывается с общей библиотекой во времени выполнения (связанный, когда процесс запускается, не связанный позже с dlload()), где это ищет ту общую библиотеку (.so) файл кроме LD_LIBRARY_PATH?
Фон:
У меня есть некоторый код C++, что я записал, что это пользуется конкретной сторонней библиотекой. Я установил библиотеку и скомпилировал мой код двух различных платформ, и Ubuntu, но различных версий, и различные версии gcc также. Библиотека была скомпилирована и установлена из источника и расположена в /usr/local/lib на обеих платформах. Когда я компилирую свой код, я связываюсь с pkg-config --libs параметры для сторонней библиотеки и я проверил это pkg-config --libs возвраты та же самая вещь на обеих платформах.
Мой код компилирует успешно на обеих платформах, и LD_LIBRARY_PATH не определяется (или определяется как пустой: "") на обеих платформах. Однако, когда я выполняю его на одной platoform, это хорошо работает, и на другом я получаю эту ошибку:
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 ... Я думаю, что даже не было необходимости. [ 1110]