Ldd linux нет so

Команда ldd предназначена для вызова одноименной утилиты, осуществляющей вывод списка разделяемых библиотек, используемых исполняемыми файлами или разделяемыми библиотеками. Разделяемые библиотеки обычно содержат реализации функций, которые необходимы для корректной работы приложений или других разделяемых библиотек. Разделяемые библиотеки (*.so) являются полным аналогом динамических библиотек (*.dll) из Windows.

Базовый синтаксис команды выглядит следующим образом:

$ ldd [параметры] [путь-к-разделяемой-библиотеке]

Утилита поддерживает параметр -v, позволяющий выводить дополнительную информацию о версиях используемых разделяемых библиотек, параметр -u, позволяющий выводить список связанных, но не используемых разделяемых библиотек, а также параметры -d и -r, позволяющие осуществлять релокации объектов данных и функций.

Рассматриваемая утилита может понадобиться в процессе разработки программного обеспечения, а также создания пакетов для его распространения.

Стоит упомянуть и о том, что система кэширует информацию о доступных разделяемых библиотеках и хранит ее в файле с именем /etc/ld.so.cache (файл не предназначен для редактирования с помощью обычного текстового редактора). Существует и файл конфигурации /etc/ld.so.conf, в котором содержится список путей к директориям, в которых размещены разделяемые библиотеки. Разделяемая библиотека с именем ld-linux-*.so выполняет функции динамического линковщика, то есть, осуществляет поиск необходимых для работы приложения разделяемых библиотек в кэше и загружает их. Помимо этого существует системная утилита ldconfig, предназначенная для обновления кэша разделяемых библиотек.

Также существует вспомогательная виртуальная разделяемая библиотека linux-vdso.so (или linux-gate.so на некоторых архитектурах), которая отображается ядром Linux в адресное пространство всех пользовательских процессов и используется библиотекой языка C libc для повышения производительности при работе с некоторыми системными вызовами. На нее не стоит обращать особого внимания.

Примеры использования

Вывод списка разделяемых библиотек, используемых приложением

Для вывода списка разделяемых библиотек, используемых приложением, следует передать утилите путь к интересующему приложению.

$ ldd /bin/nano
linux-vdso.so.1 (0x00007ffc5e1d3000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007fed3b9e8000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fed3b9b8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed3b7c7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fed3b7c1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fed3ba8f000)

Как видно, для работы приложения nano требуется ряд разделяемых библиотек, причем первой библиотекой является вспомогательная библиотека ядра Linux, а последней — библиотека динамического линковщика.

Вывод списка разделяемых библиотек, используемых разделяемой библиотекой

Для вывода списка разделяемых библиотек, используемых другой разделяемой библиотекой, следует передать утилите путь к интересующей разделяемой библиотеке.

$ ldd /lib/x86_64-linux-gnu/libc-2.30.so
/lib64/ld-linux-x86-64.so.2 (0x00007f8d28fad000)
linux-vdso.so.1 (0x00007ffe62b78000)

Библиотека libc использует лишь вспомогательные разделяемые библиотеки.

$ ldd /lib/x86_64-linux-gnu/libbz2.so.1
linux-vdso.so.1 (0x00007ffc757cb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3bd62f4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3bd6516000)

Библиотека libbz2 использует библиотеку libc.

Вывод подробного списка разделяемых библиотек, используемых приложением

Для вывода подробного списка разделяемых библиотек, используемых приложением, следует использовать параметр -v.

$ ldd -v /bin/nano
linux-vdso.so.1 (0x00007fff4cfcf000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007f43c1744000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f43c1714000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f43c1523000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f43c151d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f43c17eb000)

Version information:
/bin/nano:
libtinfo.so.6 (NCURSES6_TINFO_5.4.20040208) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.0.19991023) => /lib/x86_64-linux-gnu/libtinfo.so.6
libc.so.6 (GLIBC_2.27) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.6) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libncursesw.so.6 (NCURSESW6_5.7.20081102) => /lib/x86_64-linux-gnu/libncursesw.so.6
libncursesw.so.6 (NCURSESW6_5.1.20000708) => /lib/x86_64-linux-gnu/libncursesw.so.6
/lib/x86_64-linux-gnu/libncursesw.so.6:
libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.9.20150530) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.5.20051010) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.1.20000708) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.2.20001021) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.6.20061217) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.7.20081102) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.8.20110226) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.4.20040208) => /lib/x86_64-linux-gnu/libtinfo.so.6
libtinfo.so.6 (NCURSES6_TINFO_5.0.19991023) => /lib/x86_64-linux-gnu/libtinfo.so.6
/lib/x86_64-linux-gnu/libtinfo.so.6:
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/libdl.so.2:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6

Информация о версиях библиотек приведена в разделе Version information.

Источник

Linux — SO file not found

I have a program which requires liblog4cpp installed to run.

Now, I want the program to run on another machine without liblog4cpp . So I just find the log4cpp.so and move it to the same directory of my program. But at running error reported:

error while loading shared libraries: liblog4cpp.so.4: cannot open shared object file: No such file or directory

Am I doing it right? How can I tell the program to find the SO file just beside it?

6 Answers 6

Check your LD_LIBRARY_PATH environment variable. One of the directories on the path should point to the location of your log4cpp.so file; also the linux command ldd is handy for determining which shared object libraries are being used in your executable. The syntax is ldd .

In addition to what others are suggesting, consider adding the file to the dynamic linker’s cache. You can do it like this:

To add it to the loader’s cache use the following command: ldconfig

Then in order to verify that it was correctly added, run this:

assuming that the path where the .so file/s is available is /path you can also avoid to export an environment variable and just use

beware the fact that if you do:

you are resetting LD_LIBRARY_PATH to a single value /path and losing anything you added before to this environment variable. If you want to add a value without losing the previous ones

export LD_LIBRARY_PATH to the path of the library. This env variable works much like the PATH variable. It can contain multiple paths separated by :.

In the rc script from where you are launching your program, you should set the LD_LIBRARAY_PATH before launching the application. Remember, the .so are the shared libraries, it is required at the run time to link. Thus, it should be available in the standard path like /usr/lib before launching. In case it is not copied in the standard path like /usr/lib then specify the path by using the following.

Ideally, I would have placed this .so in the standard path like /usr/lib. If it is installed in the standard path, then there is no need to set the above path. Remember, to make your program better, put the new path in ldconfig.conf.

You can debug such errors by using the following.

Источник

How to find out the dynamic libraries executables loads when run?

I want to find out the list of dynamic libraries a binary loads when run (With their full paths). I am using CentOS 6.0. How to do this?

8 Answers 8

You can do this with ldd command:

readelf -d $executable | grep ‘NEEDED’

Can be used if you can’t run the executable, e.g. if it was cross compiled, or if you don’t trust it:

In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library dependencies. Be aware, however, that in some circumstances, some versions of ldd may attempt to obtain the dependency information by directly executing the program. Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.

Note that libraries can depend on other libraries, so now you need to find the dependencies.

A naive approach that often works is:

but the more precise method is to understand the ldd search path / cache. I think ldconfig is the way to go.

Choose one, and repeat:

/maps for running processes

Mentioned by Basile, this is useful to find all the libraries currently being used by running executables. E.g.:

shows all currently loaded dynamic dependencies of init (PID 1 ):

This method also shows libraries opened with dlopen , tested with this minimal setup hacked up with a sleep(1000) on Ubuntu 18.04.

Источник

Ldd linux нет so

В прошлый раз мы с Вами обнаружили, что запуск программ, скомпилированных вместе с динамическими библиотеками, вызывает ошибку:

Это сообщение выдает загрузчик динамических библиотек(динамический линковщик — dynamic linker), который в нашем случае не может обнаружить библиотеку libfsdyn.so. Для настройки динамического линковщика существует ряд программ.

Первая программа называется ldd. Она выдает на экран список динамических библиотек используемых в программе и их местоположение. В качестве параметра ей сообщается название обследуемой программы. Давайте попробуем использовать ее для нашей программы rezultdyn:

Как видите все правильно. Программа использует три библиотеки:

libc.so.6 — стандартную библиотеку функций языка C++.
ld-linux.so.2 — библиотеку динамической линковки программ ELF формата.
libfsdyn.so — нашу динамическую библиотеку функций.

Нашу библиотеку она найти не может. И правильно! Динамический линковщик ищет библиотеки только в известных ему каталогах, а каталог нашей программы ему явно не известен.

Для того, чтобы добавить нашу директорию с библиотекой в список известных директорий надо подредактировать файл /etc/ld.so.conf. Например, у меня этот файл состоит из таких строк:

Во всех этих директории хранятся всеми используемые библиотеки. В этом списке нет лишь одной директории — /lib, которая сама по себе не нуждается в описании, так как она является главной. Получается, что наша библиотека станет «заметной», если поместить ее в один их этих каталогов, либо отдельно описать в отдельном каталоге. Давайте для теста опишем, добавим строку в конец файла ld.so.conf:

У меня этот файл валяется в домашнем каталога пользователя root, у Вас он может быть в другом месте. Теперь после этого динамический линковщик будет знать где можно найти наш файл, но после изменения конфигурационного файла ld.so.conf необходимо, чтобы система перечитала настройки заново. Это делает программа ldconfig. Пробуем запустить нашу программу:

Как видите все заработало 🙂 Если теперь Вы удалите добавленную нами строку и снова запустите ldconfig, то данные о расположении нашей библиотеки исчезнут и будет появляться таже самая ошибка.

Но описанный метод влияет на всю систему в целом и требует доступа администратора системы, т.е. root. А если Вы простой пользователь без сверх возможностей ?!

Для такого случая есть другое безболезненное решение. Это использование специальной переменной среды LD_LIBRARY_PATH, в которой перечисляются все каталоги содержащие пользовательские динамические библиотеки. Для того, чтобы установить эту переменную в командной среде bash надо набрать всего несколько команд. Для начала посмотрим есть ли у нас такая переменная среды:

У меня в ответ выводится пустая строка, означающая, что такой переменной среды нет. Устанавливается она следующим образом:

После этого программа rezultdyn будет прекрасно работать. В случае, если у Вас в системе эта переменная среды уже уставновлена, то, чтобы не испортить ее значение, надо новый каталог прибавить к старому значению. Делается это другой командой:

Если Вы обнулите эту переменную, то снова библиотека перестанет работать:

Вы также параллельно можете зайти в систему под другим пользователем или даже тем же самым, но если Вы захотите просмотреть значение LD_LIBRARY_PATH, то увидите ее прежнее значение. Это означает, что два разных пользователя Linux не могут влиять на работу друг друга, а это и есть самое главное хорошее отличие систем Unix от большинства других систем.

Источник