LINUX.ORG.RU

Как найти все библиотеки, которые дергаются через dlopen?

 ,


1

1

$SUBJ;

При этом без запуска бинарника.

Задача - упаковка зависимостей к бинарнику.
Проблема в том, что одна из зависимостей - SDL2_mixer, который в свою очередь через dlopen грузит libvorbis (да, я знаю, что mixer можно собрать так, чтобы он просто динамически линковался - это не выход).

Костылинг в виде strings SDL2_mixer.so | grep 'vorbis' хоть и работает, но очень уж костыль.

★★★★

strings /path/to/бинарник | grep "\.so"
anonymous ()

Может повесить обертку на dlopen через ldpreload и записывать все вызовы?

cyber_eagle ()

При этом без запуска бинарника.

Кишкой чую, в общем случае это сводится к halting problem.

anonymous ()
Ответ на: комментарий от annulen

Запусти процесс

При этом без запуска бинарника.
При этом без запуска бинарника.
При этом без запуска бинарника.

iSage ★★★★ ()
Ответ на: комментарий от anonymous

1) Он опрtделеляет soname для libvorbis на этапе configure.
2) это, опять же, костылинг и применим только в данном конкретном случае

iSage ★★★★ ()

Давайте усложним задачу:
1) на самом деле SDL_mixer дергает SDL_LoadObject, а не dlopen. А вот тот уже дергает dlopen.
2) Бинарь требует графического стека, которого нет и не надо на CI-сервере. Бинарь без иксов умрет раньше вызовов dlopen.

iSage ★★★★ ()
Ответ на: комментарий от annulen

А бинарик разве уже не может делать dlopen при некоторых условиях? Например, программа отображает png картинки через либу только для png и ей не надо отображать jpeg-и пока пользователь этого не попросит.

anonymous ()
Ответ на: комментарий от anonymous

Еще раз: нету нигде в исходниках. Дефайнится на этапе configure на то, что найдено на этой конкретной системе. В хидерах (а следовательно и в девелоп-пакетах) не дефайнится.
=> непереносимо вообще никак между дистрами.

iSage ★★★★ ()

В нормальных дистрибутивах пакет libsdl2-mixer зависит от пакета libvorbisfile. Так что если ориентироваться на них, то вы сможете сделать всё без костылей.

Sorcerer ★★★★★ ()
Ответ на: комментарий от beastie

Казалось бы, причем тут nm.
nm: libSDL2_mixer-2.0.so.0: no symbols

iSage ★★★★ ()
Ответ на: комментарий от Sorcerer

Т.е. мне нужно под каждый существующий в «нормальных дистрах» пакетный менеджер написать функцию поиска пакета по имени либы, потом зависимостей, потом поиск в пакете с зависимостью новой либы.
Офигеть простое решение.

iSage ★★★★ ()
Ответ на: комментарий от rupert

Потому что на целевой системе (CI) soname может быть другой.

iSage ★★★★ ()

ltrace?

а, тьфу, тебе ж без запуска бинарника...

demidrol ★★★★★ ()
Последнее исправление: demidrol (всего исправлений: 1)
Ответ на: комментарий от iSage

Офигеть простое решение.

А вы вообще странных вещей хотите, так что ваш путь - страдание.

Вот зачем вам so-файлы куда-то упаковывать? Обычно предоставляются deb'ки и/или rpm'ки продукта, в которых прописаны все нужные зависимости, они и подтягиваются при установке.

Т.е. мне нужно ... написать функцию поиска пакета по имени либы, потом зависимостей, потом

Если уж очень хочется заtar'ить все зависимости, то можно сравнить списки установленных .so-файлов до и после установки зависимостей.

Sorcerer ★★★★★ ()
Ответ на: комментарий от Sorcerer

Вот зачем вам so-файлы куда-то упаковывать?

AppImage

Обычно предоставляются deb'ки и/или rpm'ки продукта

Обычно предоставляются сорцы. Пакетами занимаются мейнтейнеры.
Каждый, кто хоть раз пробовал пакетировать под все популярные дистры и их версии что-нибудь сложнее helloworld знает, какой это ад. Автоматизировать это на CI - ад вдвойне.

Предоставлять только deb или только rpm - сразу обречь себя на кучу issue «а вот почему deb есть а rpm нет?» «а вот почему у вас deb под протухший debian, который не работает на моей 17й бубунте? переделайте!»

iSage ★★★★ ()
Ответ на: комментарий от anonymous

Кишкой чую, в общем случае это сводится к halting problem.

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

German_1984 ★★ ()

Никак, на то оно и динамическое. Смотреть код и документацию. И включать голову при этом, так как если твой бинарник, например, никогда не грузит vorbis аудио, то и libvorvis миксеру не нужен.

slovazap ★★★★★ ()

Генерируешь список экспортируемых символов библиотеки и каждый из них ищешь в бинарнике.

tailgunner ★★★★★ ()

ptrace -e open твоя_прога | grep \.so

например. Очевидно, что «дёрнуть» библиотеку можно только открыв её

ckotinko ☆☆☆ ()
Ответ на: комментарий от anonymous

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

annulen ★★★★★ ()
Ответ на: комментарий от ckotinko

ptrace -e open твоя_прога | grep \.so

Во-первых, strace. Во-вторых, лучше уж ltrace -e dlopen твоя_прога.

kawaii_neko ★★★★ ()

В общем случае никак. Хоть с запуском, хоть без запуска бинарника.

Задача - упаковка зависимостей к бинарнику.

ИМХО нужно копать в сторону automake или что там используется для сборки. Там должен быть в каком-то виде список всех используемых зависимостей.

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

Дело в том, что это же зависимость к зависимости.
Да и это все для частного случая, для которого можно хоть руками указать, хоть слинковать статически, хоть собрать sdl_mixer с динамической линковкой без dlopen.
Хочется-то универсальности.

iSage ★★★★ ()
Ответ на: комментарий от iSage

это же зависимость к зависимости

Тогда почему тебя это волнует? Зависимость к зависимости не твоя проблема, это проблема пользователя. Например если прога требует gstreamer то какие конкретно кодеки установлены для gstreamer тебя не должно волновать. Если ты завязан на определённый кодек, так что без него прога (или отдельная фича) не работает, то он должен быть _прямой_ зависимостью и в т.ч проверяться в automake.

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.