Linux какие библиотеки использует программа

Обновлено: 02.07.2024

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

Существует два типа библиотек:

Статические библиотеки: статические библиотеки для полных программ, которые не зависят от запуска внешних библиотек. Особенностью статически связанных программ является то, что они работают без установки каких-либо предварительных условий. Статическая библиотека заканчивается расширением * .a, и эти библиотеки включены (отдельная копия) в программы, для которых требуются ее функции.

Динамические библиотеки: динамические библиотеки для небольших программ по размеру. Эти библиотеки заканчиваются расширением .so. Еще одна особенность использования динамической компоновки при запуске многих программ. Она может использовать одну копию библиотеки, а не занимать память многими копиями одного и того же кода , Таким образом, последние программы используют динамическое связывание. В этой статье мы рассмотрим команды ldd, которые используются для управления разделяемыми библиотеками.

Общие библиотеки

Когда мы создаем программу, нам нужно много фрагментов кода, которые кто-то написал для выполнения обычных или специализированных функций в наших целях.

Эти фрагменты кода хранятся в разделяемых библиотеках.

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

Синтаксис и параметры

Команда ldd выводит зависимости общих объектов. Синтаксис команды:

Мы можем использовать команды ldd с опциями

  • -v: вывести всю информацию.
  • -d: перемещение данных процесса.
  • -r: данные процесса и перемещение функций.
  • -u: вывод неиспользуемых прямых зависимостей.

1) Отобразить зависимости команды

Мы будем отображать зависимости команды cp.

2) Отобразить зависимости команды с деталями

Мы будем отображать зависимости команды cp с более подробной информацией, используя опцию -v.

3) Отображение неиспользуемых прямых зависимостей команды

Мы можем отобразить неиспользуемые прямые зависимости команды cp с использованием опции -u.

4) Работа только с динамическими исполняемыми файлами

Мы выведем ldd только для динамических исполняемых файлов с использованием опции -r.

5) ldd со стандартной исполняемой командой

Когда мы пытаемся выполнить ldd со стандартной командой, например ls, нам нужен полный путь к динамическому исполняемому файлу.

Мы видим, что ldd утверждает, что он не может найти ls.

Но с абсолютным путем ldd работал нормально.

6) Установите, что данный исполняемый демон поддерживает TCP Wrapper

Чтобы определить, поддерживает ли данный исполняемый демона TCP Wrapper или нет, выполните следующую команду.

Результат показывает, что демон OpenSSH (sshd) поддерживает TCP Wrapper.

7) ldd с отсутствующей зависимостью

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

Как только мы обнаружили недостающую зависимость, мы можем установить ее или обновить кеш командой ldconfig.

Мы будем выполнять перемещение и сообщать о любых недостающих объектах (только ELF), набрав команду ниже.

Мы будем выполнять перемещение для объектов и функций данных и сообщать о любых недостающих объектах или функциях (только для ELF), набрав команду ниже.

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

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

По умолчанию библиотеки в Linux находятся в двух папках. Это корневая папка /lib в ней находятся библиотеки, которые используют программы, расположенные в корневой папке /bin.

И есть вторая папка /usr/lib . В ней находятся библиотеки, которые используют программы расположенные /usr/bin . Пути к библиотекам указаны файле /etc/ld.so.conf . Данный файл можно просмотреть стандартным способом, через утилиту cat.

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

В данной директории мы можем видеть 2 файла конфигурации, в зависимости от версии и наполнения операционной системы их может быть и больше. Ну и соответственно в конфигурационных файлах находятся пути к директориям, где лежат необходимые для работы библиотеки. Если мы ставим какое, то свое программное обеспечение, которому необходимы дополнительные библиотеки, не идущие в составе дистрибутива linux, то в данной директории может создаться свой конфигурационный файл. Например: если мы используем систему виртуализации VMware , то к каждой VM устанавливаем VMware tools то данное программное обеспечение создаст свой конфигурационный файл с путями для своих библиотек.

Переходим в директорию cd /etc/ и отсортируем так, чтобы в результатах все, что содержит ld.

Видим 3 основных конфигурационных файла. ld.so.conf - это файл конфигурации в котором написано откуда брать дополнительные библиотеки. Директория ls.so.conf.d в которой находятся дополнительные конфигурационные файлы и ld.so.cache это кэш библиотек. Он у нас выстраивается каждый раз для того, чтобы программы при необходимости при запросе библиотек не копались в файлах, а сразу брали из загруженного в оперативную память кэша. Т.е. если мы вносим какие-то изменения в файл конфигурации, добавляем какие-то конфигурационные файлы нам необходимо обновить этот кэш. Кэш обновляется командой ldconfig . Этого, собственно, достаточно, чтобы прогрузить все библиотеки в кэш.

Давайте посмотрим, как, определить какими библиотеками пользуется какая программа.

Для этого мы будем использовать команду ldd и путь к бинарному файлу. Например: Программа ls которая используется для вывода списка файлов в каталоге. Она находится в каталоге /bin/ls .

В результате получим мы следующее:

Мы видим, какие so использует данная программа и соответственно ссылки на них, где они расположены, собственно, so - это наши библиотеки в данном случае.

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

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

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

изменить" / bin "выше на" / " для поиска всех каталогов.

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

У меня не было ldd на моей цепочке инструментов руки, поэтому я использовал objdump:

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

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

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

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

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

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

> $ ldd / path/to / program

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

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

$ objdump-p /path/to/program | grep необходимо

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

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

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

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

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

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

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

readelf -d рекурсия

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

выбрать один, и повторяю:

/proc/<pid>/maps для выполнения процессов

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

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

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

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

лдд executable_name|у awk ''|команды xargs dpkg о -С |на awk -е ":" ''

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

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

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

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

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

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

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

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

Редактировать - убрал "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

Это также должно быть безопасно, в отличие от того, ldd которое не должно использоваться на ненадежных исполняемых файлах. Кроме того, obbjdump -p показывает дополнительную информацию, такую ​​как RPATH , которая может быть полезна при исследовании проблем динамического связывания с вашим исполняемым файлом. +1 за метод, который на самом деле безопасен и надежен (у меня почему-то есть система, в которой musl-gcc регулярно создаются двоичные файлы, так что вызов ldd двоичного файла просто выполняет двоичный файл , поэтому в настоящее время мне регулярно напоминают о том, насколько небезопасно ldd ).

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

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

Используйте это, чтобы выяснить, действительно ли mariadb использует tc-malloc , который загружается LD_PRELOAD. Прекрасно работает. Я искал что-то, что показывало бы мне «.so» для данного pid. Это именно то, что мне было нужно. Спасибо!

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

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

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

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

> $ ldd / path / to / program

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

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

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

readelf -d рекурсия

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: