Как показать все общие библиотеки, используемые исполняемыми файлами в Linux?

linux shared-libraries

289229 просмотра

12 ответа

1291 Репутация автора

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

Автор: Alan Szlosek Источник Размещён: 08.09.2008 05:02

Ответы (12)


47 плюса

11758 Репутация автора

чтобы узнать, какие библиотеки использует бинарный файл, используйте ldd

ldd path/to/the/tool

Вы должны написать небольшой сценарий оболочки, чтобы добраться до вашей общесистемной разбивки.

Автор: pilif Размещён: 08.09.2008 05:04

249 плюса

4274 Репутация автора

Решение
  1. Используйте lddдля отображения общих библиотек для каждого исполняемого файла.
  2. Очистить вывод
  3. Сортировать, вычислить количество, сортировать по количеству

Чтобы найти ответ для всех исполняемых файлов в каталоге "/ bin":

find /bin -type f -perm /a+x -exec ldd {} \; \
| grep so \
| sed -e '/^[^\t]/ d' \
| sed -e 's/\t//' \
| sed -e 's/.*=..//' \
| sed -e 's/ (0.*)//' \
| sort \
| uniq -c \
| sort -n

Измените "/ bin" выше на "/", чтобы найти все каталоги.

Вывод (только для каталога / bin) будет выглядеть примерно так:

  1 /lib64/libexpat.so.0
  1 /lib64/libgcc_s.so.1
  1 /lib64/libnsl.so.1
  1 /lib64/libpcre.so.0
  1 /lib64/libproc-3.2.7.so
  1 /usr/lib64/libbeecrypt.so.6
  1 /usr/lib64/libbz2.so.1
  1 /usr/lib64/libelf.so.1
  1 /usr/lib64/libpopt.so.0
  1 /usr/lib64/librpm-4.4.so
  1 /usr/lib64/librpmdb-4.4.so
  1 /usr/lib64/librpmio-4.4.so
  1 /usr/lib64/libsqlite3.so.0
  1 /usr/lib64/libstdc++.so.6
  1 /usr/lib64/libz.so.1
  2 /lib64/libasound.so.2
  2 /lib64/libblkid.so.1
  2 /lib64/libdevmapper.so.1.02
  2 /lib64/libpam_misc.so.0
  2 /lib64/libpam.so.0
  2 /lib64/libuuid.so.1
  3 /lib64/libaudit.so.0
  3 /lib64/libcrypt.so.1
  3 /lib64/libdbus-1.so.3
  4 /lib64/libresolv.so.2
  4 /lib64/libtermcap.so.2
  5 /lib64/libacl.so.1
  5 /lib64/libattr.so.1
  5 /lib64/libcap.so.1
  6 /lib64/librt.so.1
  7 /lib64/libm.so.6
  9 /lib64/libpthread.so.0
 13 /lib64/libselinux.so.1
 13 /lib64/libsepol.so.1
 22 /lib64/libdl.so.2
 83 /lib64/ld-linux-x86-64.so.2
 83 /lib64/libc.so.6

Редактировать - убрал "grep -P"

Автор: John Vasileff Размещён: 08.09.2008 05:21

4 плюса

8098 Репутация автора

С помощью lddвы можете получить библиотеки, которые используют инструменты. Чтобы оценить использование библиотек для набора инструментов, вы можете использовать что-то вроде следующей команды.

ldd /bin/* /usr/bin/* ... | sed -e '/^[^\t]/ d; s/^\t\(.* => \)\?\([^ ]*\) (.*/\2/g' | sort | uniq -c

(Здесь sedудаляются все строки, которые не начинаются с вкладки, и отфильтровываются только актуальные библиотеки. С sort | uniq -cкаждой библиотекой вы получаете счетчик, показывающий, сколько раз это происходило.)

Возможно, вы захотите добавить sort -gв конце, чтобы получить библиотеки в порядке использования.

Обратите внимание, что вы, вероятно, получите строки две небиблиотечные строки с помощью вышеуказанной команды Один из статических исполняемых файлов («не динамический исполняемый файл») и один без какой-либо библиотеки. Последнее является результатом того, linux-gate.so.1что в вашей файловой системе есть не библиотека, а «поставляемая» ядром.

Автор: mweerden Размещён: 08.09.2008 05:35

6 плюса

61 Репутация автора

В системе UNIX предположим, что двоичное (исполняемое) имя - test. Затем мы используем следующую команду для просмотра списка библиотек, используемых в тесте:

ldd test
Автор: Raghwendra Размещён: 20.04.2011 08:07

45 плюса

1561 Репутация автора

В Linux я использую:

lsof -P -T -p Application_PID

Это работает лучше, чем lddкогда исполняемый файл использует загрузчик не по умолчанию

Автор: Fabiano Tarlao Размещён: 17.11.2011 11:54

62 плюса

3257 Репутация автора

У меня не было ldd на моем ARM toolchain, поэтому я использовал objdump:

$ (CROSS_COMPILE) objdump -p

Например:

objdump -p /usr/bin/python:

Dynamic Section:
  NEEDED               libpthread.so.0
  NEEDED               libdl.so.2
  NEEDED               libutil.so.1
  NEEDED               libssl.so.1.0.0
  NEEDED               libcrypto.so.1.0.0
  NEEDED               libz.so.1
  NEEDED               libm.so.6
  NEEDED               libc.so.6
  INIT                 0x0000000000416a98
  FINI                 0x000000000053c058
  GNU_HASH             0x0000000000400298
  STRTAB               0x000000000040c858
  SYMTAB               0x0000000000402aa8
  STRSZ                0x0000000000006cdb
  SYMENT               0x0000000000000018
  DEBUG                0x0000000000000000
  PLTGOT               0x0000000000832fe8
  PLTRELSZ             0x0000000000002688
  PLTREL               0x0000000000000007
  JMPREL               0x0000000000414410
  RELA                 0x0000000000414398
  RELASZ               0x0000000000000078
  RELAENT              0x0000000000000018
  VERNEED              0x0000000000414258
  VERNEEDNUM           0x0000000000000008
  VERSYM               0x0000000000413534
Автор: smichak Размещён: 20.03.2013 10:28

7 плюса

599 Репутация автора

На OS X по умолчанию нет ldd, objdumpили lsof. В качестве альтернативы попробуйте otool -L:

$ otool -L `which openssl`
/usr/bin/openssl:
    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
    /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

В этом примере использование which opensslзаполняет полный путь для данной исполняемой и текущей пользовательской среды.

Автор: bluebadge Размещён: 27.01.2015 12:29

18 плюса

753 Репутация автора

Проверьте зависимости общей библиотеки исполняемого файла программы

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

> $ ldd / path / to / program

Обратите внимание, что НЕ рекомендуется запускать ldd с любым ненадежным сторонним исполняемым файлом, потому что некоторые версии ldd могут напрямую вызывать исполняемый файл для определения его библиотечных зависимостей, что может представлять угрозу безопасности.

Вместо этого, более безопасный способ показать зависимости библиотеки неизвестного двоичного файла приложения - использовать следующую команду.

$ objdump -p / path / to / program | ГРЕП НУЖЕН

для получения дополнительной информации

Автор: kayle Размещён: 24.04.2015 04:53

8 плюса

164991 Репутация автора

readelf -d рекурсия

redelf -dпроизводит аналогичный вывод, objdump -pкоторый был упомянут по адресу: https://stackoverflow.com/a/15520982/895245

Но имейте в виду, что динамические библиотеки могут зависеть от других динамических библиотек, которые вам придется использовать.

Пример:

readelf -d /bin/ls | grep 'NEEDED'

Образец выхода:

 0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libacl.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Затем:

$ locate libselinux.so.1
/lib/i386-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libselinux.so.1
/mnt/debootstrap/lib/x86_64-linux-gnu/libselinux.so.1

Выберите один и повторите:

readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED'

Пример вывода:

0x0000000000000001 (NEEDED)             Shared library: [libpcre.so.3]
0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

И так далее.

/proc/<pid>/maps для запуска процессов

Это полезно, чтобы найти все библиотеки, которые в данный момент используются исполняемыми файлами. Например:

sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u

показывает все загруженные в данный момент динамические зависимости init(PID 1):

/lib/x86_64-linux-gnu/ld-2.23.so
/lib/x86_64-linux-gnu/libapparmor.so.1.4.0
/lib/x86_64-linux-gnu/libaudit.so.1.0.0
/lib/x86_64-linux-gnu/libblkid.so.1.1.0
/lib/x86_64-linux-gnu/libc-2.23.so
/lib/x86_64-linux-gnu/libcap.so.2.24
/lib/x86_64-linux-gnu/libdl-2.23.so
/lib/x86_64-linux-gnu/libkmod.so.2.3.0
/lib/x86_64-linux-gnu/libmount.so.1.1.0
/lib/x86_64-linux-gnu/libpam.so.0.83.1
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
/lib/x86_64-linux-gnu/libpthread-2.23.so
/lib/x86_64-linux-gnu/librt-2.23.so
/lib/x86_64-linux-gnu/libseccomp.so.2.2.3
/lib/x86_64-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libuuid.so.1.3.0

Этот метод также показывает библиотеки, открытые с dlopenпомощью этой минимальной установки, взломанной с помощью sleep(1000)Ubuntu 18.04.

Смотрите также: https://superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089

Автор: Ciro Santilli 新疆改造中心996ICU六四事件 Размещён: 26.03.2017 08:57

2 плюса

2870 Репутация автора

в пакетах печати Ubuntu, связанных с исполняемым файлом

ldd executable_name|awk '{print $3}'|xargs dpkg -S |awk -F  ":"  '{print $1}'
Автор: Shimon Doodkin Размещён: 04.04.2017 12:41

0 плюса

1 Репутация автора

Я нашел этот пост очень полезным, так как мне нужно было исследовать зависимости от сторонней библиотеки (32 или 64-битные пути выполнения).

Я собрал рекурсивный bash-скрипт Q & D, основанный на предложении 'readelf -d' для дистрибутива RHEL 6.

Он очень простой и будет проверять каждую зависимость каждый раз, даже если она могла быть проверена ранее (то есть очень многословно). Выход тоже очень простой.

#! /bin/bash

recurse ()
# Param 1 is the nuumber of spaces that the output will be prepended with
# Param 2 full path to library
{
#Use 'readelf -d' to find dependencies
dependencies=$(readelf -d ${2} | grep NEEDED | awk '{ print $5 }' | tr -d '[]')
for d in $dependencies; do
   echo "${1}${d}"
   nm=${d##*/}
   #libstdc++ hack for the '+'-s
   nm1=${nm//"+"/"\+"}
   # /lib /lib64 /usr/lib and /usr/lib are searched
   children=$(locate ${d} | grep -E "(^/(lib|lib64|usr/lib|usr/lib64)/${nm1})")
   rc=$?
   #at least locate... didn't fail
   if [ ${rc} == "0" ] ; then
      #we have at least one dependency
      if [ ${#children[@]} -gt 0 ]; then
         #check the dependeny's dependencies
         for c in $children; do
          recurse "  ${1}" ${c}
         done
      else
         echo "${1}no children found"
      fi
   else
      echo "${1}locate failed for ${d}"
   fi
done
}
# Q&D -- recurse needs 2 params could/should be supplied from cmdline
recurse "" !!full path to library you want to investigate!!

перенаправить вывод в файл и grep для «найдено» или «не удалось»

Используйте и изменяйте, на свой страх и риск, конечно, как вы хотите

Автор: Anders Domeij Размещён: 19.10.2017 02:20

1 плюс

46 Репутация автора

Еще один вариант можно просто прочитать файл, расположенный на

/proc/<pid>/maps

Например, если идентификатор процесса равен 2601, то команда

cat /proc/2601/maps

И вывод как

7fb37a8f2000-7fb37a8f4000 r-xp 00000000 08:06 4065647                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37a8f4000-7fb37aaf3000 ---p 00002000 08:06 4065647                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf3000-7fb37aaf4000 r--p 00001000 08:06 4065647                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf4000-7fb37aaf5000 rw-p 00002000 08:06 4065647                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf5000-7fb37aafe000 r-xp 00000000 08:06 4065646                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37aafe000-7fb37acfd000 ---p 00009000 08:06 4065646                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acfd000-7fb37acfe000 r--p 00008000 08:06 4065646                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acfe000-7fb37acff000 rw-p 00009000 08:06 4065646                    /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acff000-7fb37ad1d000 r-xp 00000000 08:06 3416761                    /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37ad1d000-7fb37af1d000 ---p 0001e000 08:06 3416761                    /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1d000-7fb37af1e000 r--p 0001e000 08:06 3416761                    /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1e000-7fb37af1f000 rw-p 0001f000 08:06 3416761                    /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1f000-7fb37af21000 r-xp 00000000 08:06 4065186                    /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37af21000-7fb37b121000 ---p 00002000 08:06 4065186                    /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37b121000-7fb37b122000 r--p 00002000 08:06 4065186                    /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37b122000-7fb37b123000 rw-p 00003000 08:06 4065186                    /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
Автор: SoSen Размещён: 30.11.2018 09:43
Вопросы из категории :
32x32