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

Question

Как только приложение связано с динамическими библиотеками, которое требуется, можно ли узнать, какая именно библиотека вытащила другую, которую я вижу в списке?

Например, сегодня у меня была ситуация, когда библиотека, которая не должна была быть там вообще, присутствовала на выходе ldd и искажала приложение. По логическому выводу я мог бы разобраться в этом и изолировать проблему, а затем перестроить соответствующий проект, чтобы больше не включать неисправную библиотеку. Но можно ли сделать то же самое без каких-либо дополнительных знаний о приложении и библиотеках, от которых он зависит, используя экстернальный инструмент от подобных ldd? (Проблема заключалась в том, что рассматриваемая библиотека не использовалась непосредственно приложением, а другая библиотека, к которой приложение напрямую связывалось.)

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

Answer 1

Чтобы это знать, вам придется использовать рекурсивно readelf. Сначала запустите его в своем исполняемом файле и найдите библиотеки NEEDED. Это скажет вам, что ваш исполняемый файл нуждается напрямую. После этого вы должны итеративно повторять процесс для каждой библиотеки, которая необходима, и как только вы прибудете в библиотеку, вы узнаете путь включения.

Answer 2

Запустите ldd в каждой из библиотек, о которой сообщает ldd executable. Продолжайте рекурсивно до тех пор, пока не будет найден преступник.

В качестве альтернативы, запустите

objdump -p /path/to/program-or-library | grep NEEDED 

рекурсивно.

Answer 3

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.