|
Утилита ldd выводит информацию о зависимостях совместно используемых библиотек (shared object dependencies).
SYNOPSIS
ldd [option]... file...
ОПИСАНИЕ
ldd напечатает список shared-объектов (совместно используемых библиотек), необходимых каждой программе или для программы (или библиотеки), указанной в командной строке. Ниже показан пример использования ldd для анализа зависимостей ls:
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffff7fc1000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007ffff7f53000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff7c00000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007ffff7ebc000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc3000)
В обычном случае ldd запустит standard dynamic linker (см. ld.so(8)) с переменной окружения LD_TRACE_LOADED_OBJECTS, установленной в 1. Это приведет к тому, что dynamic проверит динамические зависимости программы, найдет (в соответствии с правилами, описанными в ld.so(8)) и загрузит объекты, которые удовлетворяют эти зависимости. Для каждой зависимости ldd покажет место размещения соответствующего объекта и адрес (в hex-формате), по которому он загружен (shared-зависимости linux-vdso и ld-linux относятся к специальным, см. vdso(7) и ld.so(8)).
Безопасность. Имейте в виду, что при определенных обстоятельствах (например, когда программа указывает ELF-интерпретатор, отличающийся от ld-linux.so), некоторые версии ldd могут попытаться получить информацию о зависимости путем попытки прямого запуска программы, что может привести к запуску любого кода, определенного в ELF-интерпретаторе программы, и возможно к выполнению самой программы. Например, в версиях glibc до 2.27 утилита это делала, хотя большинство дистрибутивов предоставляли модифицированную версию без этой "фичи".
Таким образом, никогда не следует применять ldd на исполняемом коде, к которому нет доверия, поскольку это может привести к выполнению произвольного (потенциально опасного) кода. Более безопасная альтернатива для обработки untrusted исполняемых файлов:
$ objdump -p /path/to/program | grep NEEDED
Однако следует отметить, что эта альтернатива покажет только прямые зависимости исполняемого кода, в то время как ldd покажет полное дерево зависимостей исполняемого кода.
ОПЦИИ
--version
Напечатает номер версии ldd.
-v, --verbose
Напечатает всю информацию, включая, к примеру информацию версии символов.
-u, --unused
Напечатает не используемые прямые зависимости (начиная с 2.3.4.).
-d, --data-relocs
Выполнит релокации и сообщит о любых отсутствующих объектах (только для ELF).
-r, --function-relocs
Выполнит релокации как для объектов данных, так и для функций, и сообщит о любых отсутствующих объектах или функциях (только для ELF).
--help Подсказка по использованию.
BUGS
ldd не работает на a.out shared-библиотеках.
ldd не работает с некоторыми очень старыми программами a.out, которые были собраны до того, как в релизы компилятора была добавлена поддержка ldd. Если вы используете ldd на одной из таких программах, то программа попытается запуститься с argc = 0, и результат может быть непредсказуемым.
СМ. ТАКЖЕ
pldd(1), sprof(1), ld.so(8), ldconfig(8).
[Ссылки]
1. man objdump.
2. man ldconfig.
3. man pldd. |
