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

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

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

Статически собранные программы характеризуются тем, что могут корректно функционировать в любых условиях, и не зависят от наличия или отсутствия разделяемых библиотек, что может оказаться полезным в ситуациях, когда возникают конфликты версий разделяемых библиотек, или когда системные библиотеки повреждены или недоступны (например во время восстановления операционной системы после серьезного сбоя). К недостаткам таких исполняемых файлов следует отнести то, что они имеют значительный размер и для обновления программы необходимо полностью заменить ее исполняемый файл – например, если несколько статически собранных программ, которые работают с архивами ZIP, содержат ошибку, то для исправления ошибки необходимо заменить все эти программы, что может быть затруднено (например, будет трудно точно установить, какие именно программы содержат ошибочный код и нуждаются в обновлении). Кроме того, статически собранные программы не умеют совместно использовать совпадающие участки кода, что ведет к излишнему расходу системных ресурсов.

Динамически собранные исполняемые файлы для корректной работы требуют наличия файлов разделяемых библиотек, и соответственно при их отсутствии/повреждении не могут корректно функционировать, но зато для обновления программы и исправления ошибки часто оказывается достаточным просто заменить соответствующую разделяемую библиотеку, после чего ошибка исчезает во всех программах, которые эту библиотеку используют динамически. Динамически связанные программы также значительно меньше по объему, чем статически связанные, и код разделяемых библиотек может использоваться одновременно многими программами – что позволяет экономить системные ресурсы.

Подавляющее большинство программ в современных дистрибутивах Linux являются динамически собранными. Определить тип исполняемого файла (статический ли он либо с динамическим связыванием) можно, например, с помощью команды ldd:

# ldd /bin/su
linux-gate.so.1 => (0xb77d0000)
libpam.so.0 => /lib/libpam.so.0 (0xb77be000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb77bb000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb765f000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb765b000)
/lib/ld-linux.so.2 (0xb77d1000)

Но здесь нас подстерегает несколько НО:

1) Существует способ загрузки библиотек в обход ldd, функцией dlopen(). Такие библиотеки в выводе ldd не отображены.

2) Принцип работы ldd состоит в следующем: она устанавливает переменную окружения LD_TRACE_LOADED_OBJECTS, а затем запускает программу на исполнение. Входящий в libc загрузчик динамических библиотек (для GNU glibc это ld-linux.so) проверяет наличие этой переменной. Если она установлена, то вместо нормального запуска программы он выводит список используемых ею динамически подгружаемых библиотек и завершает работу.

То есть, мало того, что не все библиотеки (в идеале) мы сможем увидеть, так ещё и запускаем на исполнение файл! А если это руткит? Что же делать? Выход есть, правда не совсем удобный.

Выход первый (для пункта 2): использовать вместо ldd -> lddsafe (https://github.com/rg3/lddsafe) Скрипт использует objdump и безопасен, так как не запускает на исполнение проверяемую программу.

Выход второй (для пунктов 1 и 2): использовать команду strace. Правда вывод не такой удобный будет, как в случае с ldd.

Так же можно эту информацию получить и таким образом:

# readelf -d /sbin/fsck / grep ‘NEEDED’
0x00000001 (NEEDED) Shared library: [libblkid.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

Для более детальной вычинки бинарника можно использовать утилиту objdump и strace.

Что же делать, если вы получаете сообщения такого плана:

error while loading shared libraries: xxxx.so.0
cannot open shared object file no such file or directory

Это значит, что нет подходящих библиотек. Но что делать, если они есть, а система их не находит? На помощь приходит утилита ldconfig, которая управляет динамическими библиотеками.

С помощью этой программы вы можете добавить свои библиотеки, просматривать кеш библиотек. Список подключаемых библиотек находится в файле /etc/ld.so.conf, а кеш (собственно откуда берут информацию /lib/ld-linux.so) — /etc/ld.so.cache.

— Посмотреть список библиотек

# ldconfig -p | grep mysql
libmysqlclient_r.so.15 (libc6) => /usr/lib/libmysqlclient_r.so.15
libmysqlclient.so.15 (libc6) => /usr/lib/libmysqlclient.so.15

Подробнее можно узнать в справочном руководстве.

Так же можно использовать переменную окружения LD_LIBRARY_PATH.

Примечание.

В Solaris это можно сделать командой dtrace. Кстати, есть хорошая новость — её пытаются портировать на Linux.

Во FreeBSD используется команда truss

Источник

Как в Linux узнать зависимости уже установленного (portable) приложения?

Как выяснить список всех необходимых пакетов / библиотек для работы конкретного portable приложения в Linux, если это приложение не имеет ни репозитория ни deb-пакета?

Конкретно задача связана с FreeFileSync который ни хочет запускать диалог выбора папки в KDE Plasma на Kubuntu 14.04.05. Если установить весь xubuntu-desktop то начинает работать, если только xfce4 — не начинает. Ставить весь Xubuntu-desktop не хочу, из него начинаются проблемы в KDE (сбрасывается ряд настроек окружения, повисает видимое окно plasma-desktop в верхнем левом углу и соответствующий пункт в панели задач). В общем нужно как то выяснить, чего конкретно не хватает FreeFileSync. Чем это можно сделать? Либо просто скажите, что ему нужно. В Доках смотрел — не нашёл.

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

Либо зависимости должны быть указаны разработчиком продукта на его сайте.

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

Запусти из консоли и почитай, на что ругается. Ещё попробуй ldd ./my_app и посмотри, чего не находит.

Источник

8 Примеров команд LDD в Linux

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

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

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

Статические библиотеки: статические библиотеки для полных программ, которые не зависят от запуска внешних библиотек. Особенностью статически связанных программ является то, что они работают без установки каких-либо предварительных условий. Статическая библиотека заканчивается расширением * .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), набрав команду ниже.

Источник

[Ubuntu] Зависимости исполняемого файла

Я слышал, что есть такая чудо-утилита под названием ldd, которая показывает, от каких dll-ок зависит мой исполняемый файл. Прогнал своё поделие через неё, и она мне выдал кучу библиотек, многие из которых имеют ничего мне не говорящие имена (откуда они там взялись — одному Богу известно)

Как мне по этой информации узнать, от каких deb пакетов зависит моя программа? одним словом, чё мне писать в графе Depends при использование checkinstall?

Эмм. А какие инклуды то хоть?

dpkg -S имя файла

Ты что, не знаешь какие библиотеки ты использовал? Наверняка в dpkg есть функци чтобы посмотреть какому пакету принадлежит файл.

И что с этим делать?

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

Мне нужен универсальный метод быстро получить зависимости, типа:

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

Use debhelper, Luke!

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

тонко
man apt-file

ТС, ты тот еще тормоз, к примеру, показывает мой хеллоуворд зависимость libc.so.6, в зависимости значит нужно пихать glibc, как то так.

> а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль

это не линукс-вэй =) Здесь нужно вначале сделать тучу бесполезных времязатратных телодвижений, т.е. заняться сексом

но я не хочу привязываться к конкретной версии ssl

посмотри, какие симлинки есть на libcrypto.so.0.9.8, мб просветлит..

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

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

резюме: предлагаю попросить в этом деле помощи у Бога лично

> Мне нужен универсальный метод быстро получить зависимости, типа:

Просто феерическая наглость.

Даю хинт. Этот универсальный метод называется «нанять человека, который разбирается в устройстве юникс и решит эту задачу за тебя».

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

Ты не знаешь, какие библиотеки использует код, который ты сам писал? Похвально, весьма похвально.

> Просто феерическая наглость.

Ты не знаешь, какие библиотеки использует код, который ты сам писал?

жир залил весь монитор! как ты научился писать столь калорийные посты?

Источник