LINUX.ORG.RU

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

 , ,


0

2

Дано: моя программа A зависит от библиотеки B, которая подключает нужный плагин C.

Плагин подключается, только если при запуске указать LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ В противном случае, библиотека B не падает, но и плагин не находит.

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

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

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

P.s. библиотка B - это gstreamer. Запуск gstreamer через их стандартный gst-launch также требует LD_LIBRARY_PATH для подключения нужных плагинов.

★★★★★
Ответ на: комментарий от next_time

так делать нельзя в случае директории /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
LamerOk ★★★★★
()

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

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)

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

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

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

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

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

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)

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

man rpath

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

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

anonymous
()

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

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

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

anonymous
()

Возможно ли указать 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

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

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

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

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

Как же я ору.

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

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

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

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

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

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

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

Iron_Bug ★★★★★
()