Опакечивание LD_LIBRARY_PATH

Может быть ты просто кладешь плагин не в то место, где gstreamer его ищет?

плагин не находит

Тебе скорее всего надо обновить кэш библиотек пост-инсталл хуком.

Перед запуском программы проверь, что библиотека в кэше:

ldconfig -X -N -p | grep имя_библиотеки

плагин там, куда его производитель кладёт, это не мой плагин и не мой инсталлер плагина, влиять я на это не могу

обновить кэш библиотек

это как?

RTFM же.

уже - там нет ничего вменяемого

всё что я нашёл - это общесистемная хрень через ldconfig, но так делать нельзя в случае директории /lib/x86_64-linux-gnu/, по очевидным причинам

есть какой-то способ обновить кеш только для отдельного бинарника?

так делать нельзя в случае директории /lib/x86_64-linux-gnu/, по очевидным причинам

А в чём заключается "очевидность причин"?

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"


$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

У меня оно тоже самое выводит. Но без export LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ нужные плагины не подхватываются

libplugin.so плагины и libname.so библиотеки, это вещи никак друг с другом не связанные, я в вопросе не разбираюсь, но кажется ты считаешь библитеку плагина равнозначной просто библиотеке которая динамически линукуется динамическим линковщиков, а это не так, плагины открываются явно как файл через dlopen всегда, с этой точки plugin.so ближе к тому что лежит в /bin или вообще в /share чем к тому что лежит в /lib. По диагонали глянув gstreamer смотрит в GST_PLUGIN_PATH (судя по гуглу) или явно где ищет все файлы *.so загружает из все подряд и пытается обработать как свой плагин, вероятно попутно пробует всё что в LD_LIBRARY_PATH.

Так что мне кажется ты не в ту строну копаешь. Просто погляди где gstreamer ищет плагины, и положи полагин туда и всё. Или

export GST_PLUGIN_PATH=/opt/yourpligindir

Например. Плагины, это не библиотеки (ну как бы библиотеки, но есть нюанс), это программы которые просто оформлены в виде библиотеки.

Погляди API gstreamer, там наверняка должена быть функция установки своих путей для поиска плагинов.

UDP

• https://gstreamer.freedesktop.org/documentation/gstreamer/gstregistry.html?gi-language=c

Можно сделать символическую ссылку

Есть очевидное решение с помощью запуска через .sh скрипт, но м.б. есть варианты получше.

А в чем проблема?

Расширение не обязательно. Можно наоборот переименовать бинарник, а на его место положить скрипт с прежним именем

upd. Ещё, как вариант, скрипт можно закинуть в /usr/local/bin/ с именем бинарника из /usr/bin. А бинарник запускать из скрипта по полному пути

В PATH у /usr/local/bin обычно приоритет, хотя может и не во всех дистрибутивах

Возможно ли указать LD_LIBRARY_PATH не всей программе, а только отдельному .so-шнику (я подозреваю, нет)

man rpath

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

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

https://ru.wikipedia.org/wiki/Rpath

Когда-то я использовал patchelf для патчинга готовых бинарников. Можно начать с этого

как это нормально опакетить так, чтобы можно было поставить на любую debian-based ОС деб-пакетом и не сломать ничего.

Что «это»? Ты что опакечивать собрался? Свою программу, gstreamer, его плагин или ты собрался все три запихать в один deb?

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

rpath я менял - не помогло

А в чем проблема?

особой проблемы нет, просто ищу более красивое решение

спасибо, попробую

неправильно настроил загрузку плагинов

только не я, а авторы плагина

кинь выхлоп с LD_DEBUG

там выхлоп на 50к строк

Возможно ли указать LD_LIBRARY_PATH не всей программе, а только отдельному .so-шнику (я подозреваю, нет)

Что мешает указать всей программе расширенный LD_LIBRARY_PATH?
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib/x86_64-linux-gnu

Вот тут практически готовый рецепт есть:
https://www.altlinux.org/Alfabank_eToken#Установка_pkiclient-5.00.28-0.i386.rpm

Вот тут практически готовый рецепт есть:

Оказалось, что, всё же, полноценно работать нельзя. Не получается подписать документ при попытке сделать платёж. Плюс, в какой-то момент, появилась непонятная ошибка при закрытии Java-приложения.

Комментарий от клиента Альфа-банка: К счастью, это не так: на самом деле, полноценно работать можно. Все прекрасно подписывается. Другое дело, что в самом банк-клиенте, при подписывании, нужно МЫШКОЙ нажать КНОПКУ. Если нажать ENTER на клавиатуре - происходит нажатие какой-то другой кнопки в форме ввода, передаются неверные данные и документ не подписывается.

Как же я ору.

rpath? Правда, наверное, не тот случай.

Как же я ору.

То, что ты отцитировал, не главное в контексте текущей темы. А так-то времена далёкие, может в Альфабанке что с сайтом и сделали с тех пор.

может в Альфабанке что с сайтом и сделали с тех пор

Только не факт, что в нужную сторону.

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

потому что это твой rpath, а у динамической библиотеки он свой.

гипотетически, «отдельный so-шник» можно пропатчить и вписать туда. таким занимаются иногда, когда собирают сложные тулчейны для сборки систем. есть даже софтинка patchelf. но это эклектика. на компе юзера ты не будешь переписывать куски бинарника, конечно же. как вариант - собери свой вариант библиотеки, с rpath, и поставляй его со своей софтиной. или собери в статику, если это возможно и если лицензия библиотеки позволяет.