Правильное использование пути библиотеки 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