Иерархический LDD (1)
Вопрос
Из -за использования Gentoo часто случается, что после того, как программы обновления связаны с старыми версиями библиотек. Обычно Revdep-Rebuild помогает разрешить это, но на этот раз это зависимость от библиотеки Python, и python-updater
не заберет его.
Есть ли «иерархический» вариант ldd
Что показывает мне, какая общая библиотека зависит от какой другой общей библиотеки? Большую часть времени библиотеки и исполняемые документы связаны только с несколькими другими общими библиотеками, которые, в свою очередь, были связаны с горсткой, превращая библиотечную зависимость в большой список. Я хочу знать, какую зависимость мне нужно восстановить с помощью новой версии другой библиотеки, которую я обновил.
Решение
Если вы используете Portage≥2,2 с FEATURES=preserve-libs
, вам редко нужно когда -нибудь revdep-rebuild
больше как старый .so.
VERS будет сохранен по мере необходимости (хотя вам все еще нужно тщательно восстановить, так как все еще идет кабум, когда libA.so.0
хочет libC.so.0
а также libB.so.0
хочет libC.so.1
И некоторые бинарны хотят оба libA.so.0
а также libB.so.0
).
Это сказанное, что ldd
ДЕЛАЕТ, чтобы динамический линкетер загрузил исполняемый файл или библиотеку, как обычно, но распечатайте некоторую информацию по пути. Это рекурсивный поиск библиотеки библиотеки «Библиотека нуждается в другой библиотеке и Hellip», потому что это то, что делает динамичный линкер.
В настоящее время я запускаю Linux/PPC32; На Linux/x86 динамический линкер обычно /lib/ld-linux.so.2
, и на Linux/x86_64 динамический линкер обычно /lib/ld-linux-x86-64.so.2
. Анкет Здесь я называю это напряму ldd
это не что иное, как сценарий оболочки, который призывает динамический линкер выполнять свою магию.
$ /lib/ld.so.1 /sbin/badblocks Usage: /sbin/badblocks [-b block_size] [-i input_file] [-o output_file] [-svwnf] [-c blocks_at_once] [-d delay_factor_between_reads] [-e max_bad_blocks] [-p num_passes] [-t test_pattern [-t test_pattern [...]]] device [last_block [first_block]] $ LD_TRACE_LOADED_OBJECTS=1 /lib/ld.so.1 /sbin/badblocks linux-vdso32.so.1 => (0x00100000) libext2fs.so.2 => /lib/libext2fs.so.2 (0x0ffa8000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x0ff84000) libc.so.6 => /lib/libc.so.6 (0x0fdfa000) libpthread.so.0 => /lib/libpthread.so.0 (0x0fdc0000) /lib/ld.so.1 (0x48000000) $ LD_TRACE_LOADED_OBJECTS=1 /lib/ld.so.1 /lib/libcom_err.so.2 linux-vdso32.so.1 => (0x00100000) libpthread.so.0 => /lib/libpthread.so.0 (0x6ffa2000) libc.so.6 => /lib/libc.so.6 (0x6fe18000) /lib/ld.so.1 (0x203ba000) $ grep -l pthread /sbin/badblocks /lib/libcom_err.so.2 /lib/libcom_err.so.2
/sbin/badblocks
не перечисляет libpthread.so.0
Как библиотечная зависимость, но ее втягивают libcom_err.so.2
.
Ваша проблема, что ldd
Разве не выводит красивое дерево зависимостей? Использовать ldd -v
.
$ LD_TRACE_LOADED_OBJECTS=1 LD_VERBOSE=1 /lib/ld.so.1 /sbin/badblocks linux-vdso32.so.1 => (0x00100000) libext2fs.so.2 => /lib/libext2fs.so.2 (0x0ffa8000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x0ff84000) libc.so.6 => /lib/libc.so.6 (0x0fdfa000) libpthread.so.0 => /lib/libpthread.so.0 (0x0fdc0000) /lib/ld.so.1 (0x201f9000) Version information: /sbin/badblocks: libc.so.6 (GLIBC_2.2) => /lib/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6 /lib/libext2fs.so.2: libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib/libc.so.6 libc.so.6 (GLIBC_2.2) => /lib/libc.so.6 libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 /lib/libcom_err.so.2: ld.so.1 (GLIBC_2.3) => /lib/ld.so.1 libpthread.so.0 (GLIBC_2.1) => /lib/libpthread.so.0 libpthread.so.0 (GLIBC_2.0) => /lib/libpthread.so.0 libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6 /lib/libc.so.6: ld.so.1 (GLIBC_PRIVATE) => /lib/ld.so.1 ld.so.1 (GLIBC_2.3) => /lib/ld.so.1 /lib/libpthread.so.0: ld.so.1 (GLIBC_2.3) => /lib/ld.so.1 ld.so.1 (GLIBC_2.1) => /lib/ld.so.1 ld.so.1 (GLIBC_PRIVATE) => /lib/ld.so.1 libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/libc.so.6 libc.so.6 (GLIBC_2.1) => /lib/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/libc.so.6 libc.so.6 (GLIBC_2.2) => /lib/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
Если вы хотите, вы можете прочитать заголовки ELF напрямую, а не в зависимости от динамического линкера.
$ readelf -d /sbin/badblocks | grep NEEDED 0x00000001 (NEEDED) Shared library: [libext2fs.so.2] 0x00000001 (NEEDED) Shared library: [libcom_err.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] $ readelf -d /lib/libcom_err.so.2 | grep NEEDED 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [ld.so.1]
Вы также можете man ld.so
Для других милых трюков, с которыми вы можете играть glibc
Динамический линкер.
Другие советы
Я вижу много интересных деталей, но не было прямого ответа на заданный вопрос.
«Иерархическая» версия ldd
является lddtree
(из app-misc/pax-utils
):
$ lddtree /usr/bin/xmllint
xmllint => /usr/bin/xmllint (interpreter => /lib64/ld-linux-x86-64.so.2)
libreadline.so.6 => /lib64/libreadline.so.6
libncurses.so.5 => /lib64/libncurses.so.5
libdl.so.2 => /lib64/libdl.so.2
libxml2.so.2 => /usr/lib64/libxml2.so.2
libicui18n.so.49 => /usr/lib64/libicui18n.so.49
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6
ld-linux.so.2 => /lib64/ld-linux.so.2
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libgcc_s.so.1
libicuuc.so.49 => /usr/lib64/libicuuc.so.49
libicudata.so.49 => /usr/lib64/libicudata.so.49
libz.so.1 => /lib64/libz.so.1
liblzma.so.5 => /usr/lib64/liblzma.so.5
libm.so.6 => /lib64/libm.so.6
libpthread.so.0 => /lib64/libpthread.so.0
libc.so.6 => /lib64/libc.so.6
Мне нужно что -то подобное, поэтому я написал tldd
, Здесь он показывает свои собственные библиотечные зависимости:
$ ./tldd ./tldd ./tldd └─libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003687c00000) ├─libm.so.6 => /lib64/libm.so.6 (0x0000003685000000) │ └─libc.so.6 => /lib64/libc.so.6 (0x0000003684c00000) │ └─ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003684400000) └─libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003686c00000)
Я также собирался предложить «читать -Д», но также убедиться, что вы строите с ldflags = »-wl,-с учетом», если вы еще этого не сделали. Это заставит вас сталкиваться с этой проблемой реже. Заповедные Libs Portage 2.2 хороши, но я понимаю, что это было маскировано в первую очередь из -за этого - у него есть недостатки.