Où définir LD_LIBRARY_PATH sous Solaris?

Quel est le meilleur endroit pour configurer la variable LD_LIBRARY_PATH spécifique à l'application sous Solaris? Comment fonctionneOù définir LD_LIBRARY_PATH sous Solaris?

LD_LIBRARY_PATH

travail variable?

Nous dressa dans .kshrc, mais différentes applications ont besoin de différentes versions du cadre de messagerie, mais ces applications exécutent sous le même usage et donc ils auraient besoin différents LD_LIBRARY_PATH, donc à votre avis quel est le meilleur endroit pour régler ce variable? Fondamentalement, j'essaie de comprendre comment faire de cette partie de chemin d'accès variable de l'application au lieu de spécifique à l'environnement de l'utilisateur.

Source

2009-03-02 Ville M

Habituellement, je voudrais juste avoir un script shell qui démarre l'application. Dans le script shell, je définirais LD_LIBRARY_PATH comme je le souhaite pour cette application, puis le script commencerait cette application. En procédant ainsi, le chemin ne devrait être défini que pour cette application.

Source

2009-03-02 22:11:09

Merci, c'est le long des lignes que je pensais. Cependant serait-il logique de mettre cette variable dans un fichier app_profile externe, puis d'en extraire le fichier dans le script? Ou voyez-vous des problèmes avec cela? Je pense que plusieurs applications ont besoin du même chemin qu'il serait logique de l'externaliser? –

LD_LIBRARY_PATH (ou LD_LIBRARY_PATH_32 et LD_LIBRARY_PATH_64) doit être défini avant le lancement de l'exécutable - parce que ld.so.1 le lit avant d'arriver à main() et ne le relit pas par la suite. –

@Ville - Je pense que cela fonctionnerait, mais vous aurez envie de l'essayer d'abord pour être sûr –

Vous pouvez trouver une description formelle de LD_LIBRARY_PATH sur la page de manuel pour "ld.so.1", c.-à-d. Exécuter "man ld.so.1". Il décrit également d'autres variables qui sont honorées par le lieur d'exécution.

En plus de LD_LIBRARY_PATH, les exécutables et les bibliothèques partagées peuvent également avoir un chemin de recherche intégré pour les bibliothèques. Si vous exécutez une application que vous avez liée vous-même, vous pouvez utiliser l'option -R de ld pour définir le chemin d'accès intégré (Sun CC et gcc ont tous les deux des options pour faire la même chose). Cela peut vous permettre d'éviter d'utiliser LD_LIBRARY_PATH en premier lieu.

Source

2009-03-03 21:58:18 Kenster

-1

Vous pouvez utiliser la commande crle:

crle -l/chemin/vers/votre/lib/fichier

Source

2010-01-03 02:11:47 Sedawk

crle souffre du même problème que la définition dans un fichier d'environnement global - il affecte toutes les applications, donc ne aide pas lorsque différentes applications ont besoin de versions différentes des bibliothèques. – alanc

alanc a raison. –

@alanc est * faux *. 'crle -c' vous permettra d'affecter des applications spécifiques (voir Exemple 6 sur http://docs.oracle.com/cd/E19082-01/819-2239/crle-1/index.html) – vladr

La réponse crle est la plus correcte. Sous Solaris, LD_LIBRARY_PATH ne doit pas être utilisé. Utilisez crle à la place. Pour voir les chemins actuels, lancez simplement "crle" tout seul. Pour mettre à jour la liste, utilisez crle -u -l /path/to/your/lib/directory. Le -u est nécessaire pour écrire les modifications apportées à la configuration du système, sinon la modification sera temporaire. Voir la page man pour plus d'options.

Source

2010-06-09 15:34:52

Comme indiqué dans les commentaires sur la réponse crle précédente, ce n'est pas la meilleure solution, car elle affecte * tous * les programmes, pas seulement ceux qui ont besoin d'un chemin différent de celui avec lequel ils ont été construits. Un wrapper de script shell pour définir LD_LIBRARY_PATH juste pour ces applications est beaucoup plus sûr et plus sain que de risquer des changements à tous les programmes, et est le seul moyen de gérer différentes applications nécessitant des chemins incompatibles. – alanc

@alanc, incorrect; vous pouvez utiliser 'crle -c' pour définir les environnements par application, un manifeste Windows (voir l'exemple 6 à http://docs.oracle.com/cd/E19082-01/819-2239/crle-1/index. html). – vladr

Je viens de trouver un cas où LD_LIBRARY_PATH global ne prend pas effet, j'ai dû envelopper un script et définir LD_LIBRARY_PATH avant l'application. crle est une bonne solution globale si vous avez installé beaucoup de libs sous/opt/csw/lib, via pkgutil de blastwave.

Source

2010-09-17 01:36:01 gengmao

Vous pouvez vérifier votre fichier .profile ou .profile.user.Il y aura une entrée commentée. Il est déconseillé d'être utilisé car il est cassé.Vous devriez construire les binaires en passant des valeurs à des drapeaux plutôt que d'utiliser la variable.

Source

2013-04-20 23:10:51 Iceman

Vladr, alanc est correct.

Il n'est pas recommandé de définir LD_LIBRARY_PATH sous Solaris. Du tout.

Si vous avez besoin de créer un chemin d'accès spécifique dans votre bibliothèque ou exécutable, , vous devez utiliser l'indicateur -R dans l'éditeur de liens. Si vous construisez avec gcc, alors utilisez -Wl, Rpath (je pense).

Si vous avez besoin de faire cela pour une étape de post-construction (par exemple, parce qu'il vous manque source à recompiler), elfedit (1) vous aidera beaucoup. Il est documenté dans la page de manuel, et aussi dans le Guide de bibliothèques Linker + au http://docs.oracle.com/cd/E26502_01/html/E26507/index.html

Source

2014-02-04 02:47:59

Pour des raisons de compatibilité, GCC sous Solaris comprend également '-R'. Vous pouvez toujours utiliser '-Wl, -Rsomedir' car il est alors portable sur Linux. Ou utilisez «-Wl, -rpath, somedir» qui est également compris par ex. par l'éditeur de liens d'exécution sur Solaris et Linux. – maxschlepzig

Où définir LD_LIBRARY_PATH sous Solaris?

Répondre

Questions connexes