Пути к библиотекам для приложений в CentOS
Контекст:
После недавнего обновления версии нашего серверного программного обеспечения я столкнулся с дилеммой:
У меня есть два набора приложений (Zend-сервер и разные утилиты, а также несколько утилит управления PostgreSQL), которые оба интенсивно используют определенный библиотечный файл (libpq.so). Zend поставляется со своим собственным libpq, который является единственной версией (которую я нашел), которая будет работать со всеми вещами Zend. Postgres также поставляется с собственной версией библиотеки. Они взаимоисключающие: если версия библиотеки Postgres стоит первой в LD_LIBRARY_PATH любого пользователя, который что-то делает, все утилиты Postgres будут работать, но ни один из Zend не сработает. Если Zend будет первым, то Zend будет работать, а Postgres - нет.
Библиотеки имеют одинаковые имена. Пакет libs совместимости с PostgreSQL не работает.
В нашей среде оба набора приложений используются под множеством разных непредсказуемых учетных записей пользователей на множестве разных компьютеров CentOS, поэтому используйте "правильный путь" и настройте LD_LIBRARY_PATH для каждого пользователя, а также попросите людей "использовать только приложения X" под Y аккаунтом "работать не будет.
Вопрос:
Существует ли способ для каждого приложения сказать "для этих двоичных файлов / приложений, выполняемых в папке X, ссылка на библиотеку по пути Y, но для этих других двоичных файлов ссылка на библиотеку Z"? По сути, путь к библиотеке для каждого приложения без необходимости устанавливать LD_LIBRARY_PATH или DYLD_* каждый раз, когда я получаю доступ к одному из приложений.
Я бы предпочел избегать перекомпиляции библиотек, так как это потребовало бы от меня значительных дополнительных хлопот и тестирования каждый раз, когда выходила новая версия любого набора программного обеспечения. У меня уже есть библиотеки, которые работают, они просто не будут работать для обоих наборов приложений.
2 ответа
Встроенные пути поиска
Есть один вариант, который даст вам то, что вы хотите:
При создании приложения вы можете установить LD_RUN_PATH переменная окружения, и это будет скомпилировано в приложение. В теории chrpath Команда позволит вам изменить встроенный путь в приложении без необходимости его перекомпиляции, но я никогда не проверял это сам.
chrpath доступно в Fedora, но я не могу найти авторитетный источник для, ошибочно, источника.
Вы упоминаете DYLD_* переменные, которые предполагают, что вы работаете под OS X, и в этом случае вышеуказанное может не относиться к вам. Это, безусловно, верно для Linux, но компоновщик времени выполнения OS X может работать не так (и chrpath может быть инструментом только для Linux).
Управление вашей средой
Распространенный способ управления приложением LD_LIBRARY_PATH settings - это скрипт-обертка, как предложил ewwhite, или с помощью чего-то вроде проекта Environment Modules. Это позволяет вам упаковать настройки переменных среды (и более) в отдельные блоки, чтобы вы могли сделать что-то вроде:
module load myapplication
И есть ваш PATH, LD_LIBRARY_PATH, MANPATH а все остальное настроено соответствующим образом для доступа к моему приложению. И когда вы закончите, вы можете:
module unload myapplication
Чтобы отменить изменения среды.
Обычный подход к этому в моем прошлом состоял в том, чтобы использовать скрипт-обертку для выполнения приложений. В этом сценарии оболочки LD_LIBRARY_PATH будет установлен для конкретного приложения. Переменная может быть необязательно сброшена после выполнения.