Можно ли узнать, какая библиотека загружена в другую с помощью ldd?
После того, как приложение было связано с необходимыми динамическими библиотеками, возможно ли узнать, какая именно библиотека добавлена в другую, которую я вижу в списке?
Например, сегодня у меня была ситуация, когда библиотека, которой вообще не должно было быть, присутствовала в ldd вывод, и был сбой приложения. С помощью логического вывода я мог бы выяснить это и изолировать проблему, а затем перестроить соответствующий проект, чтобы больше не включать в себя ошибочную библиотеку. Но возможно ли сделать то же самое без каких-либо дополнительных знаний о приложении и библиотеках, от которых оно зависит, с помощью внешнего инструмента, подобного ldd? (Проблема заключалась в том, что рассматриваемая библиотека не использовалась приложением напрямую, а другой библиотекой, с которой приложение связывалось напрямую.)
По сути, похоже, что я ищу способ восстановить граф зависимостей ссылок после того, как приложение было связано вместе.
Решение
Чтобы узнать это, вам придется использовать readelf рекурсивно. Сначала запустите его на вашем исполняемом файле и найдите библиотеки NEEDED. Это скажет вам, что нужно вашему исполняемому файлу напрямую. После этого вам следует многократно повторять процесс для каждой необходимой библиотеки, и как только вы придете к рассматриваемой библиотеке, вы узнаете путь включения.
Другие решения
ldd в конечном итоге это скрипт-обертка для выполнения динамического компоновщика / загрузчика с переменной LD_TRACE_LOADED_OBJECTS установить в среде. Например, следующая команда выводит так же, как ldd /bin/ls в моей системе:
user@localhost ~ $ LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.* /bin/ls
linux-gate.so.1 (0xb77bd000)
libacl.so.1 => /lib/libacl.so.1 (0xb7798000)
libc.so.6 => /lib/libc.so.6 (0xb75ef000)
libattr.so.1 => /lib/libattr.so.1 (0xb75e9000)
/lib/ld-linux.so.2 (0x80065000)
Существует множество других переменных среды для настройки динамического компоновщика, документированных в ld.so(8) страница руководства. Особый интерес для выяснения причины извлечения конкретной библиотеки LD_DEBUG=files, который отслеживает, за какими файлами идет компоновщик во время обработки исполняемого файла:
user@localhost ~ $ LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files /lib/ld-linux.so.* /bin/ls
27831: file=/bin/ls [0]; generating link map
27831: dynamic: 0x08064f0c base: 0x00000000 size: 0x0001e034
27831: entry: 0x0804bffc phdr: 0x08048034 phnum: 10
27831:
27831:
27831: file=libacl.so.1 [0]; needed by /bin/ls [0]
27831: file=libacl.so.1 [0]; generating link map
27831: dynamic: 0xb772ced8 base: 0xb7724000 size: 0x0000917c
27831: entry: 0xb77257f0 phdr: 0xb7724034 phnum: 7
27831:
27831:
27831: file=libc.so.6 [0]; needed by /bin/ls [0]
27831: file=libc.so.6 [0]; generating link map
27831: dynamic: 0xb771fda4 base: 0xb757b000 size: 0x001a8eac
27831: entry: 0xb75937b0 phdr: 0xb757b034 phnum: 11
27831:
27831:
27831: file=libattr.so.1 [0]; needed by /lib/libacl.so.1 [0]
27831: file=libattr.so.1 [0]; generating link map
27831: dynamic: 0xb7579ef0 base: 0xb7575000 size: 0x000050bc
27831: entry: 0xb7575ed0 phdr: 0xb7575034 phnum: 7
27831:
linux-gate.so.1 (0xb7749000)
libacl.so.1 => /lib/libacl.so.1 (0xb7724000)
libc.so.6 => /lib/libc.so.6 (0xb757b000)
libattr.so.1 => /lib/libattr.so.1 (0xb7575000)
/lib/ld-linux.so.2 (0x80094000)
В приведенном выше примере мы видим, что libacl.so.1 а также libc.so.6 были необходимы /bin/ls сам и libattr.so.1 был вытянут как требование libacl.so.1,
Запустите ldd для каждой библиотеки, о которой сообщает ldd executable, Продолжайте рекурсивно, пока преступник не будет найден.
Или запустить
objdump -p /path/to/program-or-library | grep NEEDED
рекурсивно.