Утилита 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.