Правильное использование пути библиотеки LD или ldconfig для программного пакета

Я знаю об общих основах использования ldconfig и LD_LIBRARY_PATH, но я надеюсь на небольшую помощь гуру в моей ситуации.

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

есть много двоичных файлов и скриптов, которые выполняются из этого каталога.

некоторые из двоичных файлов (apache, php, postgres) также могут иметь отдельные версии, установленные в системе.

так как есть может быть две версии php, недостаточно создать /etc/ld.so.conf.d/myapp.conf если система не может определить, для какой версии "myapp" использовать файл ldconfig.

Я ищу лучшие практики по настройке такой системы. Человек, который изначально настроил пакет программного обеспечения, экспортировал LD_LIBRARY_PATH Так что все приложения в системе, использовали его.

Я пытаюсь изолировать только приложения в каталоге пакетов.

некоторые параметры для работы с:

/mypack - содержит все для программного пакета

/mypack/local/lib - содержит необходимые библиотеки, которые могут быть несовместимы с системой

библиотека пример:

/mypack/local/lib/libz.so.1 => /mypack/local/lib/libz.so.1.2.3
/lib/libz.so.1 => /lib/libz.so.1.2.3

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

двоичный пример: php существует как в /mypack, так и в каталоге по умолчанию php из /mypack должен использовать libs из /mypack / local / lib и версии дистрибутива следует использовать /lib

некоторые вопросы о путях библиотеки linux: - Можно ли указать /etc / ld.Итак.conf.D / php.conf такой, что он влияет только на версию php в /mypack? - Можно ли указать путь к библиотеке на основе местоположения исполняемого файла? То есть во время выполнения, если путь исполняемого файла находится под /mypack, может ли он автоматически использовать библиотеки оттуда? - Как насчет каждого пользователя? Некоторые / большая часть системы работает на разные учетные записи пользователей. Если бы я мог установить другой путь библиотеки для каждого пользователя, это решило бы его.

2 ответов


в случае, если кто-то еще найдет это полезным, я закончил это делать перед построением:

export LD_RUN_PATH='$ORIGIN/../lib'

Это включает путь библиотеки в самом двоичном файле относительно местоположения двоичного файла. Если вы планируете использовать это в скрипте bash или в своих файлах сборки, обязательно посмотрите свое конкретное использование с $ORIGIN, так как есть случаи, когда вам нужно сделать что-то вроде \$$ORIGIN, \$$ORIGIN или $$ORIGIN, чтобы различные утилиты, участвующие в сборке, получили знак доллара правильно. Поиск этого полезного бита избавил меня от необходимости обновлять около 50 отдельных скриптов, которые запускаются как пакет для создания нашего пакета программного обеспечения.


проблема в том, что LD_LIBRARY_PATH предшествует информации, предоставляемой ldconfig. Если все, что вы хотите сделать, это иметь набор резервных библиотек для установки в системах, которые еще не имеют их, извлеките текущий набор библиотек из ldconfig и добавьте их в LD_LIBRARY_PATH

mytmp=/tmp/${USER}_junk$$
( for i in `/sbin/ldconfig -p | grep '=>' | awk '{ print $NF }'` ; do   dirname $i ; done ) | sort -r | uniq > ${mytmp}
myld=""
for j in `cat ${mytmp}` ; do myld=${j}:${myld} ; done
rm -f ${mytmp}
LD_LIBRARY_PATH=${myld}${LD_LIBRARY_PATH}:${SEP}/lib:${SEP}/lib/syslibs
export LD_LIBRARY_PATH