Я хотел бы знать, какие библиотеки используются исполняемые файлы в системе. Более конкретно, я хотел бы ранжировать, какие библиотеки используются больше всего, а также двоичные файлы, которые их используют. Как я могу это сделать?
автор: Ciro Santilli 新疆改造中心 六四事件 法轮功
11 ответов
- использовать ldd список общих библиотек для каждого исполняемого файла.
- очистка на выходе
- Сортировать, вычислять количество, Сортировать по количеству
чтобы найти ответ для всех исполняемых файлов в каталоге «/ 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
автор: John Vasileff
У меня не было ldd на моей цепочке инструментов руки, поэтому я использовал objdump:
Как заставить любую программу выполнять ваш код | Инъекция разделяемых библиотек | Linux LD_PRELOAD
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
чтобы узнать, какие библиотеки использует двоичный файл, используйте ldd
ldd path/to/the/tool
вам придется написать небольшой сценарий оболочки, чтобы добраться до вашей общесистемной разбивки.
автор: pilif
в Linux я использую:
lsof -P -T -p Application_PID
это работает лучше, чем ldd когда исполняемый файл использует не по умолчанию погрузчик
LPIC 102.3 Управление библиотеками в Linux
автор: Fabiano Tarlao
Проверьте зависимости общей библиотеки исполняемого файла программы
чтобы узнать, от каких библиотек зависит конкретный исполняемый файл, вы можете использовать команду ldd. Эта команда вызывает динамический компоновщик, чтобы узнать библиотечные зависимости исполняемого файла.
> $ ldd / path/to / program
обратите внимание, что не рекомендуется запускать ldd с ненадежным сторонним исполняемым файлом, поскольку некоторые версии ldd могут напрямую вызывать исполняемый файл для идентификации его библиотечные зависимости, которые могут представлять угрозу безопасности.
вместо этого более безопасный способ показать библиотечные зависимости неизвестного двоичного файла приложения-использовать следующую команду.
$ objdump-p /path/to/program | grep необходимо
автор: kayle
на 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
в системе UNIX предположим, что двоичное (исполняемое) имя-test. Затем мы используем следующую команду, чтобы перечислить библиотеки, используемые в тесте, —
ldd test
автор: Raghwendra
С ldd вы можете получить библиотеки, которые используют инструменты. Чтобы ранжировать использование библиотек для набора инструментов, вы можете использовать что-то вроде следующей команды.
ldd /bin/* /usr/bin/* . | sed -e ‘/^[^t]/ d; s/^t(.* => )?([^ ]*) (.*//g’ | sort | uniq -c
(здесь sed удаляет все строки, которые не начинаются с вкладки, и отфильтровывает только фактические библиотеки. С sort | uniq -c вы получаете каждую библиотеку с количеством, указывающим количество раз, когда это произошло.)
вы, возможно, захотите, чтобы добавить sort -g в конце, чтобы получить библиотеки в порядке использование.
обратите внимание, что вы, вероятно, получите строки две строки без библиотеки с вышеуказанной командой. Один из статических исполняемых файлов («не динамический исполняемый файл») и один без библиотеки. Последнее является результатом linux-gate.so.1 который не является библиотекой в вашей файловой системе, а «поставляется» ядром.
автор: mweerden
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//maps для выполнения процессов
это полезно для поиска всех библиотек, используемых в настоящее время исполняемыми файлами. Например:
sudo awk ‘/.so/’ /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 , протестированы с это минимальный setup взломан sleep(1000) на Ubuntu 18.04.
автор: Ciro Santilli 新疆改造中心 六四事件 法轮功
на ubuntu печать пакетов, связанных с исполняемым файлом
лдд executable_name|у awk »|команды xargs dpkg о -С |на awk -е «:» »
автор: Shimon Doodkin
Я нашел этот пост очень полезным, так как мне нужно было исследовать зависимости от сторонней библиотеки (32 vs 64 бит пути выполнения).
Я собрал Qreadelf-d» в дистрибутиве RHEL 6.
Это очень просто и будет проверять каждую зависимость каждый раз, даже если она могла быть протестирована раньше (i.e очень многословно). Выход тоже очень простой.
#! /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 | grep NEEDED | awk ‘< print >’ | tr -d ‘[]’) for d in $dependencies; do echo «$» nm=$ #libstdc++ hack for the ‘+’-s nm1=$ # /lib /lib64 /usr/lib and /usr/lib are searched children=$(locate $ | grep -E «(^/(lib|lib64|usr/lib|usr/lib64)/$)») rc=$? #at least locate. didn’t fail if [ $ == «0» ] ; then #we have at least one dependency if [ $ -gt 0 ]; then #check the dependeny’s dependencies for c in $children; do recurse » » $ done else echo «no children found» fi else echo «locate failed for $» fi done > # Q» !!full path to library you want to investigate!!
перенаправить вывод в файл и grep для «найдено» или «не удалось»
использовать и изменять, на свой страх и риск конечно, как вы пожелаете.
Источник: askdev.ru
Как показать все общие библиотеки, используемые исполняемыми файлами в Linux?
Я хотел бы знать, какие библиотеки используются исполняемыми файлами в моей системе. Более конкретно, я хотел бы определить, какие библиотеки используются чаще всего, наряду с двоичными файлами, которые их используют. Как я могу это сделать?
Вы, вероятно, не сможете получить точное число, если будете использовать исполняемые файлы dlopen .
- Используйте ldd для отображения общих библиотек для каждого исполняемого файла.
- Очистить вывод
- Сортировать, вычислить количество, сортировать по количеству
Чтобы найти ответ для всех исполняемых файлов в каталоге «/ 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»
Это отличный ответ (я проголосовал против), но можете ли вы объяснить команду «grep -P ‘ t. * So'»? Согласно man, это интерпретирует шаблон как регулярное выражение perl, но моя версия grep не поддерживает его (man указывает, что это общая проблема). Какой бит регулярного выражения специфичен для perl?
Я думаю, что вам может понадобиться использовать ldd -v
Имейте в ldd виду, что на самом деле исполняемый файл запускается со специальной переменной среды, и динамический компоновщик Linux распознает этот флаг и просто выводит библиотеки, а не запускает исполняемый файл. Посмотрите на источник ldd ; в моей системе это скрипт bash. Если исполняемый файл статически связан и использует системные вызовы и указывает другой загрузчик, он может совершать произвольные злые действия. Так что не используйте ldd на исполняемый файл, которому вы не доверяете.
‘ldd’ не работает для меня на кросс-скомпилированных двоичных файлах. Вопрос в том, чтобы найти библиотеки, используемые программами в текущей системе (это были бы нативные программы, как сформулировано). Это хороший ответ на это. Однако я подумал, что должен упомянуть, что вам нужно использовать что-то еще, если вы ищете общие библиотеки для программ для другой системы («readelf», упомянутый в другом ответе, работал для меня)
У меня не было 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
Это также должно быть безопасно, в отличие от того, ldd которое не должно использоваться на ненадежных исполняемых файлах.
Кроме того, obbjdump -p показывает дополнительную информацию, такую как RPATH , которая может быть полезна при исследовании проблем динамического связывания с вашим исполняемым файлом.
+1 за метод, который на самом деле безопасен и надежен (у меня почему-то есть система, в которой musl-gcc регулярно создаются двоичные файлы, так что вызов ldd двоичного файла просто выполняет двоичный файл , поэтому в настоящее время мне регулярно напоминают о том, насколько небезопасно ldd ).
В Linux я использую:
lsof -P -T -p Application_PID
Это работает лучше, чем ldd когда исполняемый файл использует загрузчик не по умолчанию
Используйте это, чтобы выяснить, действительно ли mariadb использует tc-malloc , который загружается LD_PRELOAD. Прекрасно работает.
Я искал что-то, что показывало бы мне «.so» для данного pid. Это именно то, что мне было нужно. Спасибо!
чтобы узнать, какие библиотеки использует бинарный файл, используйте ldd
ldd path/to/the/tool
Вы должны написать небольшой сценарий оболочки, чтобы добраться до вашей общесистемной разбивки.
Проверьте зависимости общей библиотеки исполняемого файла программы
Чтобы узнать, от каких библиотек зависит конкретный исполняемый файл, вы можете использовать команду ldd. Эта команда вызывает динамический компоновщик для определения библиотечных зависимостей исполняемого файла.
> $ ldd / path / to / program
Обратите внимание, что НЕ рекомендуется запускать ldd с любым ненадежным сторонним исполняемым файлом, потому что некоторые версии ldd могут напрямую вызывать исполняемый файл для определения его библиотечных зависимостей, что может представлять угрозу безопасности.
Вместо этого, более безопасный способ показать зависимости библиотеки неизвестного двоичного файла приложения — использовать следующую команду.
$ objdump -p / path / to / program | ГРЕП НУЖЕН
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//maps для запуска процессов
Это полезно, чтобы найти все библиотеки, которые в данный момент используются исполняемыми файлами. Например:
sudo awk ‘/.so/’ /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.
На 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 заполняет полный путь для данной исполняемой и текущей пользовательской среды.
В системе UNIX предположим, что двоичное (исполняемое) имя — test. Затем мы используем следующую команду для просмотра списка библиотек, используемых в тесте:
ldd test
С помощью 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 что в вашей файловой системе есть не библиотека, а «поставляемая» ядром.
Еще один вариант можно просто прочитать файл, расположенный на
/proc//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
Источник: qastack.ru
8 Примеров команд LDD в Linux
ldd – это утилита командной строки Linux, которая используется в том случае, если пользователь хочет знать зависимости от общей библиотеки исполняемого файла или даже библиотеки разделяемой библиотеки.
Библиотека представляет собой набор ресурсов, таких как подпрограммы / функции, классы, значения или спецификации типов.
Существует два типа библиотек:
Статические библиотеки: статические библиотеки для полных программ, которые не зависят от запуска внешних библиотек. Особенностью статически связанных программ является то, что они работают без установки каких-либо предварительных условий. Статическая библиотека заканчивается расширением * .a, и эти библиотеки включены (отдельная копия) в программы, для которых требуются ее функции.
Динамические библиотеки: динамические библиотеки для небольших программ по размеру. Эти библиотеки заканчиваются расширением .so. Еще одна особенность использования динамической компоновки при запуске многих программ. Она может использовать одну копию библиотеки, а не занимать память многими копиями одного и того же кода , Таким образом, последние программы используют динамическое связывание. В этой статье мы рассмотрим команды ldd, которые используются для управления разделяемыми библиотеками.
Общие библиотеки
Когда мы создаем программу, нам нужно много фрагментов кода, которые кто-то написал для выполнения обычных или специализированных функций в наших целях.
Эти фрагменты кода хранятся в разделяемых библиотеках.
Чтобы использовать их, мы связываем их с нашим кодом либо при создании программы, либо при запуске программы.
Синтаксис и параметры
Команда ldd выводит зависимости общих объектов. Синтаксис команды:
ldd [OPTION]. FILE.