je suis en train de mettre à jour différents scripts afin de les
adapter à différents environnements.
De manière générale (et c'est une question plus large), je vois
souvent des scripts démarrer par une définition des binaires utilisés,
comme par exemple:
#! /bin/sh
LS=/bin/ls
WC=/usr/bin/wc
echo le nombre de fichier est `LS|WC`
Ma première question est la suivante, pourquoi utiliser une définition
littérale alors que l'on peut utiliser PATH?
#! /bin/sh
PATH=/bin:/usr/bin
echo le nombre de fichier est `ls|wc`
Ma seconde question, plus spécifique à mon cas, puisque selon
l'architecture les binaires sont dans des lieux différents:
Mieux vaut il faire
#! /bin/sh
PATH=/opt/bin:/bin etc..
ou bien:
#! /bin/sh
if [ test archi ] then
LS=/bin/ls
else
LS=/opt/bin/ls
fi
Je crois que tu n'as pas bien compris la sémantique de $ORIGIN. Relis le message de Marc plus attentivement.
Le message de Marc n'est pas suffisamment clair. C'est quelque chose qui n'est mentionné nulle part dans les outils de développements, enfin juste dans la doc de ld sous Linux, mais aucune explication du fonctionnement, et il a l'air de désigner autre chose: une adresse mémoire (si c'est bien la fonctionnalité dont tu parles, comment cela résout-il le problème des chemins?).
Et naturellement le Linker and Libraries Guide de Sun (mais naturellement, on se demande toujours ce qui est différent... et ce qui a été copié)
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Je crois que tu n'as pas bien compris la sémantique de $ORIGIN.
Relis le message de Marc plus attentivement.
Le message de Marc n'est pas suffisamment clair. C'est quelque chose
qui n'est mentionné nulle part dans les outils de développements,
enfin juste dans la doc de ld sous Linux, mais aucune explication
du fonctionnement, et il a l'air de désigner autre chose: une adresse
mémoire (si c'est bien la fonctionnalité dont tu parles, comment cela
résout-il le problème des chemins?).
Je crois que tu n'as pas bien compris la sémantique de $ORIGIN. Relis le message de Marc plus attentivement.
Le message de Marc n'est pas suffisamment clair. C'est quelque chose qui n'est mentionné nulle part dans les outils de développements, enfin juste dans la doc de ld sous Linux, mais aucune explication du fonctionnement, et il a l'air de désigner autre chose: une adresse mémoire (si c'est bien la fonctionnalité dont tu parles, comment cela résout-il le problème des chemins?).
Et naturellement le Linker and Libraries Guide de Sun (mais naturellement, on se demande toujours ce qui est différent... et ce qui a été copié)
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article <4841860c$0$20540$, Nicolas George <nicolas$ écrit:
Les fichiers INSTALL décrivent la procédure d'installation dans des conditions normales, donc en particulier où les bibliothèques requises sont installées dans les répertoires standards. Si tu veux faire quelque chose de plus baroque avec ton système, tu en as le droit, mais tu es censé savoir comment faire.
Installer des bibliothèques dans son home est aussi une procédure normale (et d'ailleurs plus ou moins obligatoire pour les utilisateurs qui n'ont pas d'accès root). Et c'est d'ailleurs pour cela que le fichier INSTALL mentionne l'option --prefix (mais je rappelle, rien concernant le run path).
Dans l'article <4841860c$0$20540$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Les fichiers INSTALL décrivent la procédure d'installation dans des
conditions normales, donc en particulier où les bibliothèques requises sont
installées dans les répertoires standards. Si tu veux faire quelque chose de
plus baroque avec ton système, tu en as le droit, mais tu es censé savoir
comment faire.
Installer des bibliothèques dans son home est aussi une procédure
normale (et d'ailleurs plus ou moins obligatoire pour les utilisateurs
qui n'ont pas d'accès root). Et c'est d'ailleurs pour cela que le
fichier INSTALL mentionne l'option --prefix (mais je rappelle, rien
concernant le run path).
Dans l'article <4841860c$0$20540$, Nicolas George <nicolas$ écrit:
Les fichiers INSTALL décrivent la procédure d'installation dans des conditions normales, donc en particulier où les bibliothèques requises sont installées dans les répertoires standards. Si tu veux faire quelque chose de plus baroque avec ton système, tu en as le droit, mais tu es censé savoir comment faire.
Installer des bibliothèques dans son home est aussi une procédure normale (et d'ailleurs plus ou moins obligatoire pour les utilisateurs qui n'ont pas d'accès root). Et c'est d'ailleurs pour cela que le fichier INSTALL mentionne l'option --prefix (mais je rappelle, rien concernant le run path).
Ah d'accord. Cela résout effectivement une partie des problèmes (e.g. une application fournie avec ses propres bibliothèques). Mais pas tous.
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont on peut vouloir installer un binaire par type processeur (sous des chemins différents, donc), mais avec une seule version des applications pour l'architecture en question.
Ah d'accord. Cela résout effectivement une partie des problèmes
(e.g. une application fournie avec ses propres bibliothèques).
Mais pas tous.
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont
on peut vouloir installer un binaire par type processeur (sous des
chemins différents, donc), mais avec une seule version des applications
pour l'architecture en question.
Ah d'accord. Cela résout effectivement une partie des problèmes (e.g. une application fournie avec ses propres bibliothèques). Mais pas tous.
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont on peut vouloir installer un binaire par type processeur (sous des chemins différents, donc), mais avec une seule version des applications pour l'architecture en question.
Vincent Lefevre wrote in message <20080601203631$:
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont on peut vouloir installer un binaire par type processeur
Au moins chez GNU, ce problème est déjà géré par ld.so directement.
Vincent Lefevre
Dans l'article <48431b0a$0$7877$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080601203631$:
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont on peut vouloir installer un binaire par type processeur
Au moins chez GNU, ce problème est déjà géré par ld.so directement.
Non, le ld.so.conf n'a que des chemins locaux à la machine et uniquement appartenant à root. Dans le cas d'un utilisateur qui veut installer sa propre bibliothèque accessible sur les machines du réseau, le ld.so.conf ne résout rien.
Dans l'article <48431b0a$0$7877$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080601203631$437b@prunille.vinc17.org>:
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont
on peut vouloir installer un binaire par type processeur
Au moins chez GNU, ce problème est déjà géré par ld.so directement.
Non, le ld.so.conf n'a que des chemins locaux à la machine et
uniquement appartenant à root. Dans le cas d'un utilisateur qui
veut installer sa propre bibliothèque accessible sur les machines
du réseau, le ld.so.conf ne résout rien.
Dans l'article <48431b0a$0$7877$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080601203631$:
Le cas le plus tordu sous NFS, c'est probablement celui de GMP, dont on peut vouloir installer un binaire par type processeur
Au moins chez GNU, ce problème est déjà géré par ld.so directement.
Non, le ld.so.conf n'a que des chemins locaux à la machine et uniquement appartenant à root. Dans le cas d'un utilisateur qui veut installer sa propre bibliothèque accessible sur les machines du réseau, le ld.so.conf ne résout rien.
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Pour citer un cas peu fréquent (une fois par an...) où le LD_LIBRARY_PATH a un intérêt : Cf http://olivierberger.com/weblog/index.php/2008/05/18/103-declaration-d-impots-sous-debian-testing-difficultes-mais-contournement-trouve « Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir complètement quitté iceweasel) : lancer iceweasel depuis le répertoire contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :
$ cd /usr/lib/iceweasel/ $ LD_LIBRARY_PATH=. iceweasel » (ça concerne au moins Debian Etch et Debian Sid)
Note : iceweasel est le firefox en marque blanche chez Debian.
Sinon on peut penser à des outils comme tsocks (« transparent socks », qui utilise LD_PRELOAD) ou valgrind (débogage/analyse, qui utilise LD_LIBRARY_PATH), de manière transparente pour l'utilisateur.
Librement,
-- Benoît Sibaud
Bonjour,
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement
sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Pour citer un cas peu fréquent (une fois par an...) où le
LD_LIBRARY_PATH a un intérêt :
Cf
http://olivierberger.com/weblog/index.php/2008/05/18/103-declaration-d-impots-sous-debian-testing-difficultes-mais-contournement-trouve
«
Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir
complètement quitté iceweasel) : lancer iceweasel depuis le répertoire
contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :
$ cd /usr/lib/iceweasel/
$ LD_LIBRARY_PATH=. iceweasel
»
(ça concerne au moins Debian Etch et Debian Sid)
Note : iceweasel est le firefox en marque blanche chez Debian.
Sinon on peut penser à des outils comme tsocks (« transparent socks »,
qui utilise LD_PRELOAD) ou valgrind (débogage/analyse, qui utilise
LD_LIBRARY_PATH), de manière transparente pour l'utilisateur.
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Pour citer un cas peu fréquent (une fois par an...) où le LD_LIBRARY_PATH a un intérêt : Cf http://olivierberger.com/weblog/index.php/2008/05/18/103-declaration-d-impots-sous-debian-testing-difficultes-mais-contournement-trouve « Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir complètement quitté iceweasel) : lancer iceweasel depuis le répertoire contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :
$ cd /usr/lib/iceweasel/ $ LD_LIBRARY_PATH=. iceweasel » (ça concerne au moins Debian Etch et Debian Sid)
Note : iceweasel est le firefox en marque blanche chez Debian.
Sinon on peut penser à des outils comme tsocks (« transparent socks », qui utilise LD_PRELOAD) ou valgrind (débogage/analyse, qui utilise LD_LIBRARY_PATH), de manière transparente pour l'utilisateur.
Librement,
-- Benoît Sibaud
Nicolas George
Vincent Lefevre wrote in message <20080602024559$:
Non, le ld.so.conf n'a que des chemins locaux à la machine et uniquement appartenant à root.
Je n'ai pas parlé de ld.so.conf.
J'ai l'impression que l'essentiel de tes reproches vient surtout de ta méconnaissance des outils.
Vincent Lefevre wrote in message
<20080602024559$0607@prunille.vinc17.org>:
Non, le ld.so.conf n'a que des chemins locaux à la machine et
uniquement appartenant à root.
Je n'ai pas parlé de ld.so.conf.
J'ai l'impression que l'essentiel de tes reproches vient surtout de ta
méconnaissance des outils.
Pour citer un cas peu fréquent (une fois par an...)
Une fois par an, justement. Ce n'est pas l'utilisation quotidienne.
Vincent Lefevre
Dans l'article <4843c14e$0$5025$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080602024559$:
Non, le ld.so.conf n'a que des chemins locaux à la machine et uniquement appartenant à root.
Je n'ai pas parlé de ld.so.conf.
J'ai l'impression que l'essentiel de tes reproches vient surtout de ta méconnaissance des outils.
Évidemment, ce sont des outils non documentés dans les procédures de compilation/installation standard (et la page man de ld.so n'indique rien qui pourrait résoudre le problème). Et tu ne me facilites pas la tâche en n'expliquant rien.
Dans l'article <4843c14e$0$5025$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080602024559$0607@prunille.vinc17.org>:
Non, le ld.so.conf n'a que des chemins locaux à la machine et
uniquement appartenant à root.
Je n'ai pas parlé de ld.so.conf.
J'ai l'impression que l'essentiel de tes reproches vient surtout de ta
méconnaissance des outils.
Évidemment, ce sont des outils non documentés dans les procédures de
compilation/installation standard (et la page man de ld.so n'indique
rien qui pourrait résoudre le problème). Et tu ne me facilites pas la
tâche en n'expliquant rien.
Dans l'article <4843c14e$0$5025$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080602024559$:
Non, le ld.so.conf n'a que des chemins locaux à la machine et uniquement appartenant à root.
Je n'ai pas parlé de ld.so.conf.
J'ai l'impression que l'essentiel de tes reproches vient surtout de ta méconnaissance des outils.
Évidemment, ce sont des outils non documentés dans les procédures de compilation/installation standard (et la page man de ld.so n'indique rien qui pourrait résoudre le problème). Et tu ne me facilites pas la tâche en n'expliquant rien.
Dans l'article <4843c19b$0$5025$, Nicolas George <nicolas$ écrit:
Benoit SIBAUD wrote in message <g20ag7$rsd$:
Pour citer un cas peu fréquent (une fois par an...)
Une fois par an, justement. Ce n'est pas l'utilisation quotidienne.
N'empêche que cela justifie pleinement l'écriture d'un wrapper modifiant le LD_LIBRARY_PATH (ceci dit, c'est ici suffisamment simple pour qu'un wrapper ne soit pas réellement utile).
D'autre part, ce n'est qu'un exemple. L'utilisateur peut être amené à faire le même genre de manip pour d'autres choses.
Dans l'article <4843c19b$0$5025$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Benoit SIBAUD wrote in message <g20ag7$rsd$1@news.rd.francetelecom.fr>:
Pour citer un cas peu fréquent (une fois par an...)
Une fois par an, justement. Ce n'est pas l'utilisation quotidienne.
N'empêche que cela justifie pleinement l'écriture d'un wrapper
modifiant le LD_LIBRARY_PATH (ceci dit, c'est ici suffisamment
simple pour qu'un wrapper ne soit pas réellement utile).
D'autre part, ce n'est qu'un exemple. L'utilisateur peut être
amené à faire le même genre de manip pour d'autres choses.
Dans l'article <4843c19b$0$5025$, Nicolas George <nicolas$ écrit:
Benoit SIBAUD wrote in message <g20ag7$rsd$:
Pour citer un cas peu fréquent (une fois par an...)
Une fois par an, justement. Ce n'est pas l'utilisation quotidienne.
N'empêche que cela justifie pleinement l'écriture d'un wrapper modifiant le LD_LIBRARY_PATH (ceci dit, c'est ici suffisamment simple pour qu'un wrapper ne soit pas réellement utile).
D'autre part, ce n'est qu'un exemple. L'utilisateur peut être amené à faire le même genre de manip pour d'autres choses.
