LINUX.ORG.RU

как заставить искать .so в каталоге исполняемого файла


0

0

Как добиться того, чтобы программка находила свои разделяемые библиотеки, находящиеся в том же каталоге, откуда она была запущена, без специальных усилий со стороны пользователя (напр. установки LD_LIBRARY_PATH)?

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

Еще раз немного иными словами. Программка устанавливалается в выбранный пользователем каталог, туда же помещает свои библиотеки, после чего безо всяких дополнительных усилий их находит, будучи вызванной по полному пути не из текущего каталога. Как реализовать эту мечту?

Использовать $ORIGIN у меня не получилось (не оказывает никакого эффекта вообще) хотя это, вроде бы, именно то, что нужно.

anonymous

тут как раз и нужна опция для компилятора:
   -Wl,-rpath,./lib
Потом если положить нужные либы в папку ./lib то прога будет их  юзать приоритетно оттуда. 
Это всё гут, но вот меня мучает проблема: а ведь сами либы тоже депендятся от других... Например я положил в ./lib библиотеку libSDL.so а она депендится на libstdc++.so.6. Все подряд либы хранить нереально.. В общем как победить до конца я еще не понял :(

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

Поможет ли твой совет в ситуации, когда 1. Приложение (бинарник) установлено в /usr/local/vasya, библиотеки в /usr/local/vasya/lib 2. Текущий каталог /tmp 3. Приложение запускается командой /usr/local/vasya/Vasya ?

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

Придется тогда тебе каким-то конфигурированием заниматься. Можно попробовать скриптик для ./configure переписать под твои требования. Или ты хочешь бинарник ставить? Тогда бинарник и другие библиотеки могут откомпилироваться со ссылками на либы в текущем каталоге, а при установке скриптом сделать корректные линки на реальные нужные библиотеки. Я бы попробовал сделать именно так, хотя раньше этого не делал. Попробуй, протестируй и доложи о результатах :)

anonymous_incognito ★★★★★
()

IMHO libtool вам в руки - после зборки можете запихивать ваши либы куда угдно а бинарники ту да же. И все будет работать как прикажете libtool. Оно для этого и сделано, и все чаще идет со связкой automake autoconf.

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

Поможет ли Ваш совет относительно libtool в ситуации, когда "программка устанавливалается в выбранный пользователем каталог"? Подразумевается, что пользователь получает ее в бинарном виде.

Если честно, то у меня есть ощущение, что libtool в современной жизни (при наличии нормального dlopen, etc) бесполезен, но, возможно, я что-то упускаю ...

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

>Придется тогда тебе каким-то конфигурированием заниматься. Можно >попробовать скриптик для ./configure переписать под твои >требования. Или ты хочешь бинарник ставить?

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

>Тогда бинарник и другие библиотеки могут откомпилироваться со >ссылками на либы в текущем каталоге, а при установке скриптом >сделать корректные линки на реальные нужные библиотеки.

За идею с линками спасибо. Я как-то забыл о существовании такого подхода, хотя он успешно применяется и работает.

>Я бы попробовал сделать именно так, хотя раньше этого не делал.

Вообще-то, для решения таких проблем на Санах всю жизнь включали в rpath путь, базирующийся от переменной $ORIGIN. Мне случайно встретилось упоминание, что на linux этот механизм существует, но заставить его работать мне никак не удается.

Неприятность в том, что искать поисковиками (например, в mail листах gcc) слово "$ORIGIN" практически смертельно ;(.

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

>Поможет ли твой совет в ситуации, когда 1. Приложение (бинарник) установлено в /usr/local/vasya, библиотеки в /usr/local/vasya/lib 2. Текущий каталог /tmp 3. Приложение запускается командой /usr/local/vasya/Vasya

Конечно поможет!!! Я сужу по тому как это было сделано в играх от Loki: они ставятся например в /usr/games/game а везде делают симлинки. Если прога коммерческая и исходники неоступны, то это самый нормальный выход.

Esh ★★★★
()

Блина, а написать скрипт, который запускает прогу в среде с переменной LD_LIBRARY_PATH=. кто или что мешает?

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

>Конечно поможет!!!

Конечно не поможет.

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

>Блина, а написать скрипт, который запускает прогу в среде с переменной LD_LIBRARY_PATH=. кто или что мешает?

Написать такой скрипт мешает желание найти более аккуратное решение.

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

> Написать такой скрипт мешает желание найти более аккуратное решение.

Боже мой, а про идеологию юниксвей вы не слышали?

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

Как написано выше, на Санах эта тривиальная задача решается удачным rpath.

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

Если Вы имеет ввиду что-то иное, то буду признателен за краткий обзор или ссылку на источник.

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

Всем спасибо. Я полный тормоз, потому что

g++ -Wl,rpath,'$ORIGIN' ccc.cpp bbb.so

порождает a.out, который замечательно находит bbb.so, лежащую в одном каталоге с ним, вне зависимости от того, откуда и как он был вызван.

Фича появился в glibc 2.1

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

> g++ -Wl,rpath,'$ORIGIN' ccc.cpp bbb.so

Ну вот, а то я уже успел подумать, что $ORIGIN действительно не работает в gcc. Ведь программировать под линукс, я пока что, честно говоря, только учусь, а то всё под винды до сих пор пишу.

> Всем спасибо.

:-) Тебе тоже.

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

Уж если даже и мне спасибо сказали, то придется добавить забытую черточку перед rpath

g++ -Wl,-rpath,'$ORIGIN' ccc.cpp bbb.so

;)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.