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