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

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

Запусти процесс, во время работы распечатай /proc/$pid/maps

Или man ld-linux

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

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

Посмотреть в исходниках что он загружает.

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

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

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

Костылинг это как раз делать что-то другое.

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

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

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

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

Не костыль стринги, а используй специально для этого существующую тулзу nm.

А почему нельзя один раз запустить бинарник с LD_DEBUG?

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

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

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

ltrace?

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

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

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

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

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

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

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

AppImage

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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