Caminhos de biblioteca por aplicativo no CentOS

Question

Contexto:

Após uma atualização recente da versão de um monte de nosso software para servidores, encontrei-me em um dilema:

Eu tenho dois conjuntos de aplicativos (servidor Zend e utilitários diversos e vários utilitários de gerenciamento PostgreSQL) que usam um determinado arquivo de biblioteca (libpq.so). O Zend vem com sua própria libpq, que é a única versão (que eu encontrei) que funcionará com todas as coisas do Zend. O Postgres também vem com sua própria versão da biblioteca. Os dois são mutuamente exclusivos: se a versão da biblioteca do Postgres vier primeiro no LD_LIBRARY_PATH de qualquer usuário que esteja fazendo alguma coisa, todos os utilitários do Postgres funcionarão, mas nenhum dos do Zend funcionará. Se o Zend chegar primeiro, o Zend irá funcionar, mas o material do Postgres não.

As bibliotecas têm os mesmos nomes. O pacote de bibliotecas de compatibilidade do PostgreSQL não funciona.

Em nosso ambiente, os dois conjuntos de aplicativos são usados em várias contas de usuário diferentes e imprevisíveis em várias máquinas CentOS diferentes, portanto, usando o "caminho certo" e definindo LD_LIBRARY_PATH por usuário e informando às pessoas "apenas" usar aplicativos X na conta Y "não funcionará.

Pergunta:

Existe uma maneira por aplicativo de dizer "para esses binários / aplicativos executados na pasta X, linkar com uma biblioteca no caminho Y, mas para esses outros binários, linkar com a biblioteca Z"? Basicamente, um caminho de biblioteca por aplicativo, sem precisar definir LD_LIBRARY_PATH ou DYLD_ * toda vez que eu acessar um dos aplicativos.

Eu preferiria evitar a necessidade de recompilar as bibliotecas, pois isso significaria uma quantidade adicional significativa de problemas e testes toda vez que uma nova versão de um conjunto de softwares for lançada. Eu já tenho bibliotecas que funcionam, elas simplesmente não funcionam nos dois conjuntos de aplicativos.

    

Answer 1

Caminhos de pesquisa incorporados

Existe uma opção que lhe dará o que você deseja:

Ao criar um aplicativo, você pode definir a variável de ambiente LD_RUN_PATH e isso será compilado no aplicativo. Em teoria, o comando chrpath permitirá que você modifique o caminho incorporado em um aplicativo sem precisar recompilá-lo, mas eu mesmo nunca testei isso.

chrpath está disponível no Fedora, mas não consigo encontrar uma fonte autorizada para o, err, source.

Você menciona DYLD_* variables, o que sugere que você está trabalhando no OS X, caso em que o acima pode não se aplicar a você. Isso é certamente verdade para o Linux, mas o vinculador de tempo de execução do OS X pode não operar da mesma maneira (e o chrpath pode ser uma ferramenta somente do Linux).

Gerenciando seu ambiente

Uma maneira comum de gerenciar configurações LD_LIBRARY_PATH por aplicativo é um script de wrapper, como sugerido por ewwhite, ou usando algo como Módulos de ambiente projeto. Isso permite empacotar configurações de variáveis de ambiente (e mais) em unidades distintas para que você faça algo como:

module load myapplication

E tenha seu PATH , LD_LIBRARY_PATH , MANPATH e todo o restante configurado apropriadamente para acessar myapplication . E quando terminar, você pode:

module unload myapplication

Para desfazer as alterações no ambiente.

    

Answer 2

A abordagem normal para isso no meu background tem sido usar um script wrapper para executar os aplicativos. Nesse script de wrapper, o LD_LIBRARY_PATH seria definido para o aplicativo específico. A variável pode opcionalmente ser desativada após a execução ser concluída.