Determine direct shared object dependencies of a Linux binary?
How can I easily find out the direct shared object dependencies of a Linux binary in ELF format? I’m aware of the ldd tool, but that appears to output all dependencies of a binary, including the dependencies of any shared objects that binary is dependent on.
4 Answers 4
You can use readelf to explore the ELF headers. readelf -d will list the direct dependencies as NEEDED sections.
$ readelf -d elfbin Dynamic section at offset 0xe30 contains 22 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x400520 0x000000000000000d (FINI) 0x400758 . This is great. Unlike ldd, readelf can inspect a cross-platform binary (i.e. inspect an ARM executable from x86-64 linux.)
If you want to find dependencies recursively (including dependencies of dependencies, dependencies of dependencies of dependencies and so on)…
ldd would not work with an executable — only for finding out the dependencies of shared libraries it is useful.
The objdump tool can tell you this information. If you invoke objdump with the -x option, to get it to output all headers then you’ll find the shared object dependencies right at the start in the «Dynamic Section».
For example running objdump -x /usr/lib/libXpm.so.4 on my system gives the following information in the «Dynamic Section»:
Dynamic Section: NEEDED libX11.so.6 NEEDED libc.so.6 SONAME libXpm.so.4 INIT 0x0000000000002450 FINI 0x000000000000e0e8 GNU_HASH 0x00000000000001f0 STRTAB 0x00000000000011a8 SYMTAB 0x0000000000000470 STRSZ 0x0000000000000813 SYMENT 0x0000000000000018 PLTGOT 0x000000000020ffe8 PLTRELSZ 0x00000000000005e8 PLTREL 0x0000000000000007 JMPREL 0x0000000000001e68 RELA 0x0000000000001b38 RELASZ 0x0000000000000330 RELAENT 0x0000000000000018 VERNEED 0x0000000000001ad8 VERNEEDNUM 0x0000000000000001 VERSYM 0x00000000000019bc RELACOUNT 0x000000000000001b The direct shared object dependencies are listing as ‘NEEDED’ values. So in the example above, libXpm.so.4 on my system just needs libX11.so.6 and libc.so.6 .
It’s important to note that this doesn’t mean that all the symbols needed by the binary being passed to objdump will be present in the libraries, but it does at least show what libraries the loader will try to load when loading the binary.
Определить зависимости бинарника от packages в Linux(Ubuntu)?
Есть ли способ определения какие packages и каких версий понадобятся при развертке приложения?
Я могу получить список всех so посредством ldd, но там не указано в какие packages входят эти библиотеки.
У вас есть какой-то бинарник, а не нормальный пакет, который вы собираетесь «разворачивать»? Зависимости по уровням версий есть только на уровне работы с пакетами, при работе с бинарниками можно ориентироваться только на версию ABI. Лучше свяжитесь с тем, кто компилировал бинарник, чтобы уточнить с какими версиями библиотек он линковался.
Во-первых, почему не указали это сразу? Во-вторых, рекомендуем и желателен именно традиционный подход к сборке пакетов. В официальных репах дебиана и убунты нет ни одного пакета собранных cpack´ом. В-третьих, apt-file´ом находите все пакеты, в которых используются файлы из отчёта ldd и пишите их в зависимости, но это будет во-о-от такой рогатый костыль.
Мне всё-таки до сих пор не понятно. Невозможно спросить разработчика на предмет зависимостей и адаптировать этот список под реалии дистрибутива?
Почему не указал? Очень просто, я не спрашивал как мне собрать пакет, я спрашивал как найти зависимости, остальное меня не интересует, на данный момент. В контексте моего вопроса присутствие cpack совершенно не важно.
Разработчика спросить можно, это я. Но я хочу четкий список зависимостей из бинарника, а не из того, что я знаю, что я использовал.
Другими словами: есть способ достичь того, чего я хочу или нет? Без советов как мне создать пакет, просто ответьте на мой вопрос, пожалуйста.
Тогда никак, архитектура elf этого не предоставляет. В голову приходят мысли о специальной среде, позволяющей собирать и тестировать бинарник с разными версиями библиотек (тот же buildbot), но это довольно объёмная задача.
Когда-то давно у меня была самописная игрушка, использовавшая libSDL, libSDL_mixer, libSDL_image, physfs, lua. Тогда я собирал пакет прописывая их как зависимости, естественно отбрасывая libpng, zlib, libc и пр., так как от них и так зависят используемые мной библиотеки. Если же хотите привязаться к версиям, то можете просто указать >= текущая_версия_пакета.
Спасибо! Я вот что нашел, но приведенный там скрипт не работает, ибо я нашел только игру pacman 🙂 А дополненный скрипт не существует, может наведет кого-нибудь на идею…
Ну, вот вам адаптированный под Debian вариант (pacman — пакетный менеджер в Arch):
#!/bin/bash
LIBS=`ldd $1 | awk »`
PKGS=`(for lib in $LIBS; do
apt-file -Fl search $lib
done) | sort | uniq`
(for pkg in $PKGS; do
echo $pkg `apt-cache show $pkg | grep Version | awk »`
done)
Проверяем:
[~]% test.sh /usr/bin/mc
e2fslibs 1.41.12-2
libc6 2.11.2-13
libcomerr2 1.41.12-2
libglib2.0-0 2.28.2-1
libgpm2 1.20.4-3.3
libpcre3 8.12-3
libslang2 2.2.2-4
Теперь смотрим, как же оно на самом деле:
[~]% apt-cache show mc | grep Depends
Depends: e2fslibs (>= 1.41.0), libc6 (>= 2.3), libcomerr2 (>= 1.01), libglib2.0-0 (>= 2.24.0), libgpm2 (>= 1.20.4), libslang2 (>= 2.0.7-1)
Или более детально:
[~]% apt-cache showpkg mc | grep -A1 Dependencies
Dependencies:
3:4.7.0.9-1 — e2fslibs (2 1.41.0) libc6 (2 2.3) libcomerr2 (2 1.01) libglib2.0-0 (2 2.24.0) libgpm2 (2 1.20.4) libslang2 (2 2.0.7-1) perl (0 (null)) zip (0 (null)) unzip (0 (null)) bzip2 (0 (null)) links (16 (null)) w3m (16 (null)) lynx (0 (null)) arj (0 (null)) file (0 (null)) xpdf-reader (16 (null)) pdf-viewer (0 (null)) dbview (0 (null)) odt2txt (0 (null)) gv (0 (null)) catdvi (0 (null)) djvulibre-bin (0 (null)) imagemagick (0 (null)) python (0 (null)) python-boto (0 (null)) python-tz (0 (null)) mime-support (0 (null))
Или более наглядно:
[~]% apt-cache depends mc
mc
Зависит: e2fslibs
Зависит: libc6
Зависит: libcomerr2
Зависит: libglib2.0-0
Зависит: libgpm2
Зависит: libslang2
Предлагает: perl
Предлагает: zip
Предлагает: unzip
Предлагает: bzip2
|Предлагает: links
|Предлагает: w3m
Предлагает: lynx
Предлагает: arj
Предлагает: file
|Предлагает: xpdf-reader
Предлагает:
acroread
epdfview
evince
evince-gtk
gv
okular
viewpdf.app
xpdf
zathura
Предлагает: dbview
Предлагает: odt2txt
Предлагает: gv
Предлагает: catdvi
Предлагает: djvulibre-bin
Предлагает: imagemagick
graphicsmagick-imagemagick-compat
Предлагает: python
Предлагает: python-boto
Предлагает: python-tz
Рекомендует: mime-support
А теперь обратите внимание на libpcre3, это зависимость libglib2.0-0. Чем больше у вас будет высокоуровневых библиотек, тем больше будет лишних зависимостей. Повторяю опять, зависимости надо или заполнять руками или ориентироваться на dh_shlibdeps, который тоже в свою очередь обычно нужно подстраивать под действительность. Причём я не зря вам привёл ещё и другие поля, для большинства пакетов это тоже существенные дополнения, от которых зависит его функциональность. А если ещё вспомнить про конфликты, замены, виртуальные пакеты…
[Ubuntu] Зависимости исполняемого файла
Я слышал, что есть такая чудо-утилита под названием ldd, которая показывает, от каких dll-ок зависит мой исполняемый файл. Прогнал своё поделие через неё, и она мне выдал кучу библиотек, многие из которых имеют ничего мне не говорящие имена (откуда они там взялись — одному Богу известно)
Как мне по этой информации узнать, от каких deb пакетов зависит моя программа? одним словом, чё мне писать в графе Depends при использование checkinstall?
Эмм. А какие инклуды то хоть?
Ты что, не знаешь какие библиотеки ты использовал? Наверняка в dpkg есть функци чтобы посмотреть какому пакету принадлежит файл.
$ dpkg -S linux-gate.so.1 dpkg: файл *linux-gate.so.1* не найден.$ dpkg -S libcrypto.so.0.9.8 libssl0.9.8: /lib/libcrypto.so.0.9.8 libssl0.9.8: /usr/lib/libcrypto.so.0.9.8он мне предлагает libssl0.9.8, но я не хочу привязываться к конкретной версии ssl
Мне нужен универсальный метод быстро получить зависимости, типа:
$ makemehappy executable depends: libevent libssl libawesome . а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль, и не дрожать от мысли о том, что программа не запустится из-за того, что на компе клиента нет какой-то маленькой неприметной библиотечки
>а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль, и не дрожать от мысли о том, что программа не запустится из-за того, что на компе клиента нет какой-то маленькой неприметной библиотечки
ТС, ты тот еще тормоз, к примеру, показывает мой хеллоуворд зависимость libc.so.6, в зависимости значит нужно пихать glibc, как то так.
> а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль
это не линукс-вэй =) Здесь нужно вначале сделать тучу бесполезных времязатратных телодвижений, т.е. заняться сексом
но я не хочу привязываться к конкретной версии ssl
посмотри, какие симлинки есть на libcrypto.so.0.9.8, мб просветлит..
хотя в случае libssl, возможно, есть смысл привязываться к конкретной версии. А то при ее обновлениях универсальные проги мрут как мухи)
пока мантейнеры пакетов в кровавых битвах еще не до конца выяснили, чей пакет главнее, и что куда класть, не будет тебе такой утилиты )
резюме: предлагаю попросить в этом деле помощи у Бога лично
> Мне нужен универсальный метод быстро получить зависимости, типа:
Просто феерическая наглость.
Даю хинт. Этот универсальный метод называется «нанять человека, который разбирается в устройстве юникс и решит эту задачу за тебя».
а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль, и не дрожать от мысли о том, что программа не запустится из-за того, что на компе клиента нет какой-то маленькой неприметной библиотечки
Ты не знаешь, какие библиотеки использует код, который ты сам писал? Похвально, весьма похвально.
> Просто феерическая наглость.
Ты не знаешь, какие библиотеки использует код, который ты сам писал?
жир залил весь монитор! как ты научился писать столь калорийные посты?
Всё правильно. Для меня тоже загадка, как можно не знать зависимостей кода, который сам писал.
это пока пишешь пишешь хэллоуворлды из трех строк)) код — клей для тучи библиотек. Часть линкованая, часть по принципу MIT тупо чекаутится с гитхаба и вваливается в файлы проекта. Что нужно для жизни всей этой свалке — хороший сложный вопрос)
Кратко: это виртуальный dll, используемый для реализации сисколов ч-з инструкции sysenter/sysexit.
http://www.trilithium.com/johan/2005/08/linux-gate/
>а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль
А это действительно для вас такая сложность? Не пишите ничего на компилируемых языках, они вообще очень-очень сложные.
я использовал всего 4 библиотеки (libpcre,openssl,libcurl,zlib) для них я методом научного тыка побобрал пакеты(libpcre3,openssl,libcurl3,zlib1g), но зависимостей гораздо больше
linux-gate.so.1 => (0x005d9000) libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00547000) libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x00f43000) libpcre.so.3 => /lib/libpcre.so.3 (0x00cc5000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a2a000) libm.so.6 => /lib/libm.so.6 (0x00e52000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00110000) libc.so.6 => /lib/libc.so.6 (0x0012c000) libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x00319000) libpthread.so.0 => /lib/libpthread.so.0 (0x0099e000) libidn.so.11 => /usr/lib/libidn.so.11 (0x0028a000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00b75000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00839000) librt.so.1 => /lib/librt.so.1 (0x004d3000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00fc4000) libz.so.1 => /lib/libz.so.1 (0x0066c000) libdl.so.2 => /lib/libdl.so.2 (0x00bd4000) /lib/ld-linux.so.2 (0x002fb000) libresolv.so.2 => /lib/libresolv.so.2 (0x00e8d000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00b95000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00681000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0071c000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00d62000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x005b4000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00827000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00bec000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00e37000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x005da000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x002bc000) в этот список почемуто попала libgnutls.so.26 хотя я использовал openssl. насколько я знаю libgnutsl это гнутый аналог openssl для встраеваемых систем.
вот я и не могу понять с какой стороны разгребать этот список