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
Mettre les home des utilisateurs dans le ld.so.conf serait un très gros trou de sécurité.
Sous solaris (qui comme linux et freebsd utilise elf) on peut faire utiliser un (équivalent de) ld.so.conf différent par exécutable, et overrider ce choix par une variable d'environnement.
Ça ne résout pas le problème où on peut se retrouver avec des timeout NFS.
Si on veut tout casser, on y arrivera toujours.
Au final, je trouve le mécanisme ELF infiniment supérieur à ce que tu décris du mécanisme mach-0.
Dès qu'on est un utilisateur sérieux, ELF présente ses limites.
Je n'ai pas encore vu décrire dans ce thread la moindre limitation du format ELF, juste une préférence contre une certaine façon de l'utiliser jugée classique par certains sous linux.
Bon je crois qu'on ne sera jamais d'accord...
Vincent Lefevre wrote:
Mettre les home des utilisateurs dans le ld.so.conf serait un très
gros trou de sécurité.
Sous solaris (qui comme linux et freebsd utilise elf) on peut faire
utiliser un (équivalent de) ld.so.conf différent par exécutable, et
overrider ce choix par une variable d'environnement.
Ça ne résout pas le problème où on peut se retrouver avec des timeout
NFS.
Si on veut tout casser, on y arrivera toujours.
Au final, je trouve le mécanisme ELF infiniment supérieur à ce que
tu décris du mécanisme mach-0.
Dès qu'on est un utilisateur sérieux, ELF présente ses limites.
Je n'ai pas encore vu décrire dans ce thread la moindre limitation du
format ELF, juste une préférence contre une certaine façon de l'utiliser
jugée classique par certains sous linux.
Mettre les home des utilisateurs dans le ld.so.conf serait un très gros trou de sécurité.
Sous solaris (qui comme linux et freebsd utilise elf) on peut faire utiliser un (équivalent de) ld.so.conf différent par exécutable, et overrider ce choix par une variable d'environnement.
Ça ne résout pas le problème où on peut se retrouver avec des timeout NFS.
Si on veut tout casser, on y arrivera toujours.
Au final, je trouve le mécanisme ELF infiniment supérieur à ce que tu décris du mécanisme mach-0.
Dès qu'on est un utilisateur sérieux, ELF présente ses limites.
Je n'ai pas encore vu décrire dans ce thread la moindre limitation du format ELF, juste une préférence contre une certaine façon de l'utiliser jugée classique par certains sous linux.
Bon je crois qu'on ne sera jamais d'accord...
Nicolas George
Vincent Lefevre wrote in message <20080530015535$:
C'est ça ou le LD_LIBRARY_PATH.
Non. D'ailleurs, tu donnes toi-même la solution ensuite.
Non il ne sait pas dès qu'il y a des bibliothèques installées dans le home de l'utilisateur (ce qui est très souvent le cas).
C'est au contraire assez rare avec une utilisation commune d'un Unix, à savoir un administrateur qui administre et des utilisateurs qui utilisent, et pas le contraire.
Vincent Lefevre wrote in message
<20080530015535$3f67@prunille.vinc17.org>:
C'est ça ou le LD_LIBRARY_PATH.
Non. D'ailleurs, tu donnes toi-même la solution ensuite.
Non il ne sait pas dès qu'il y a des bibliothèques installées dans
le home de l'utilisateur (ce qui est très souvent le cas).
C'est au contraire assez rare avec une utilisation commune d'un Unix, à
savoir un administrateur qui administre et des utilisateurs qui utilisent,
et pas le contraire.
Vincent Lefevre wrote in message <20080530015535$:
C'est ça ou le LD_LIBRARY_PATH.
Non. D'ailleurs, tu donnes toi-même la solution ensuite.
Non il ne sait pas dès qu'il y a des bibliothèques installées dans le home de l'utilisateur (ce qui est très souvent le cas).
C'est au contraire assez rare avec une utilisation commune d'un Unix, à savoir un administrateur qui administre et des utilisateurs qui utilisent, et pas le contraire.
Nicolas George
Vincent Lefevre wrote in message <20080530020839$:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de machines et qu'on veut installer telle ou telle bibliothèque pour soi, on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Vincent Lefevre wrote in message
<20080530020839$301b@prunille.vinc17.org>:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de
machines et qu'on veut installer telle ou telle bibliothèque pour soi,
on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Vincent Lefevre wrote in message <20080530020839$:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de machines et qu'on veut installer telle ou telle bibliothèque pour soi, on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
mpg
Le (on) vendredi 30 mai 2008 19:31, Nicolas George a écrit (wrote) :
Vincent Lefevre wrote in message <20080530020839$:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de machines et qu'on veut installer telle ou telle bibliothèque pour soi, on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Ça dépend de ta définition de normal. Après, moi j'aime me préoccuper de la réalité, plus que de la normalité, mais c'est une question de goût :-)
Manuel.
Le (on) vendredi 30 mai 2008 19:31, Nicolas George a écrit (wrote) :
Vincent Lefevre wrote in message
<20080530020839$301b@prunille.vinc17.org>:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de
machines et qu'on veut installer telle ou telle bibliothèque pour soi,
on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de
l'installer.
Ça dépend de ta définition de normal. Après, moi j'aime me préoccuper de la
réalité, plus que de la normalité, mais c'est une question de goût :-)
Le (on) vendredi 30 mai 2008 19:31, Nicolas George a écrit (wrote) :
Vincent Lefevre wrote in message <20080530020839$:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de machines et qu'on veut installer telle ou telle bibliothèque pour soi, on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Ça dépend de ta définition de normal. Après, moi j'aime me préoccuper de la réalité, plus que de la normalité, mais c'est une question de goût :-)
Manuel.
Vincent Lefevre
Dans l'article <48403988$0$19312$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080530015535$:
C'est ça ou le LD_LIBRARY_PATH.
Non. D'ailleurs, tu donnes toi-même la solution ensuite.
Quelle solution? Il faut bien que le chemin soit indiqué quelque part. Si ce n'est pas dans l'exécutable (directement ou indirectement), ça ne peut être que dans une variable d'environnement.
Non il ne sait pas dès qu'il y a des bibliothèques installées dans le home de l'utilisateur (ce qui est très souvent le cas).
C'est au contraire assez rare avec une utilisation commune d'un Unix, à savoir un administrateur qui administre et des utilisateurs qui utilisent, et pas le contraire.
Non, ce n'est pas rare. Visiblement tu n'y connais rien. L'administrateur ne peut en général pas s'occuper des besoins spécifiques des utilisateurs (ou si ceux-ci développent leur propre bibliothèque). Il n'y a qu'à voir le nombre de messages dans les liste de discussions concernant les chemins mal configurés...
Dans l'article <48403988$0$19312$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080530015535$3f67@prunille.vinc17.org>:
C'est ça ou le LD_LIBRARY_PATH.
Non. D'ailleurs, tu donnes toi-même la solution ensuite.
Quelle solution? Il faut bien que le chemin soit indiqué quelque part.
Si ce n'est pas dans l'exécutable (directement ou indirectement), ça
ne peut être que dans une variable d'environnement.
Non il ne sait pas dès qu'il y a des bibliothèques installées dans
le home de l'utilisateur (ce qui est très souvent le cas).
C'est au contraire assez rare avec une utilisation commune d'un
Unix, à savoir un administrateur qui administre et des utilisateurs
qui utilisent, et pas le contraire.
Non, ce n'est pas rare. Visiblement tu n'y connais rien.
L'administrateur ne peut en général pas s'occuper des besoins
spécifiques des utilisateurs (ou si ceux-ci développent leur
propre bibliothèque). Il n'y a qu'à voir le nombre de messages
dans les liste de discussions concernant les chemins mal
configurés...
Dans l'article <48403988$0$19312$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080530015535$:
C'est ça ou le LD_LIBRARY_PATH.
Non. D'ailleurs, tu donnes toi-même la solution ensuite.
Quelle solution? Il faut bien que le chemin soit indiqué quelque part. Si ce n'est pas dans l'exécutable (directement ou indirectement), ça ne peut être que dans une variable d'environnement.
Non il ne sait pas dès qu'il y a des bibliothèques installées dans le home de l'utilisateur (ce qui est très souvent le cas).
C'est au contraire assez rare avec une utilisation commune d'un Unix, à savoir un administrateur qui administre et des utilisateurs qui utilisent, et pas le contraire.
Non, ce n'est pas rare. Visiblement tu n'y connais rien. L'administrateur ne peut en général pas s'occuper des besoins spécifiques des utilisateurs (ou si ceux-ci développent leur propre bibliothèque). Il n'y a qu'à voir le nombre de messages dans les liste de discussions concernant les chemins mal configurés...
On peut aussi faire ça en ELF si on veut. C'est même ce qui se produit par défaut quand on lie avec une bibliothèque en donnant son chemin complet si elle n'a pas de soname, je crois.
Mais ce n'est pas ce qui se passe quand on faire un configure, make, make install (le truc relativement standard, quoi).
Parce que ce n'est pas la meilleure solution.
Mais c'est celle recommandée et qui est utilisée généralement.
Avec les plus courants: autotools et gcc.
Les autotools sont beaucoup décriés, un certain nombre de projets s'en écartent.
Oui, mais ce sont les plus utilisés. Et c'est le système le plus pratique actuellement pour les développeurs.
Mais j'ai déjà installé des projets utilisant les autotools qui mettaient un rpath correct.
Je suis intéressé de savoir. Lesquels?
J'en ai même vu qui refaisaient le link entre le make check et le make install parce que le rpath à utiliser n'était pas le même dans les deux cas.
Le "make check" des bibliothèques (utilisation de libtool) fait déjà un certain nombre de bidouilles (qui ne marchent pas partout) pour linker avec la bibliothèque compilée au lieu de la bibliothèque éventuellement installée (e.g. précédente version).
A noter que gcc est assez pénible à ne pas fournir par défaut des specs qui ajoutent au rpath l'emplacement de la libgcc_s.
Oui.
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
Mais il y a toujours la base du chemin à configurer quelque part.
Ben non, la base du chemin c'est $ORIGIN, ie la position de l'objet dans lequel est indiqué ce rpath. Le seul gag possible c'est le hardlink.
Mais cette position, il faut bien l'indiquer quelque part.
Dans l'article <g1os10$24n9$1@nef.ens.fr>,
Marc <marc.glisse@gmail.com> écrit:
Vincent Lefevre wrote:
On peut aussi faire ça en ELF si on veut. C'est même ce qui se produit
par défaut quand on lie avec une bibliothèque en donnant son chemin
complet si elle n'a pas de soname, je crois.
Mais ce n'est pas ce qui se passe quand on faire un configure, make,
make install (le truc relativement standard, quoi).
Parce que ce n'est pas la meilleure solution.
Mais c'est celle recommandée et qui est utilisée généralement.
Avec les plus courants: autotools et gcc.
Les autotools sont beaucoup décriés, un certain nombre de projets s'en
écartent.
Oui, mais ce sont les plus utilisés. Et c'est le système le plus
pratique actuellement pour les développeurs.
Mais j'ai déjà installé des projets utilisant les autotools qui
mettaient un rpath correct.
Je suis intéressé de savoir. Lesquels?
J'en ai même vu qui refaisaient le link entre le make check et le
make install parce que le rpath à utiliser n'était pas le même dans
les deux cas.
Le "make check" des bibliothèques (utilisation de libtool) fait déjà
un certain nombre de bidouilles (qui ne marchent pas partout) pour
linker avec la bibliothèque compilée au lieu de la bibliothèque
éventuellement installée (e.g. précédente version).
A noter que gcc est assez pénible à ne pas fournir par défaut des
specs qui ajoutent au rpath l'emplacement de la libgcc_s.
Oui.
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
Mais il y a toujours la base du chemin à configurer quelque part.
Ben non, la base du chemin c'est $ORIGIN, ie la position de l'objet dans
lequel est indiqué ce rpath. Le seul gag possible c'est le hardlink.
Mais cette position, il faut bien l'indiquer quelque part.
On peut aussi faire ça en ELF si on veut. C'est même ce qui se produit par défaut quand on lie avec une bibliothèque en donnant son chemin complet si elle n'a pas de soname, je crois.
Mais ce n'est pas ce qui se passe quand on faire un configure, make, make install (le truc relativement standard, quoi).
Parce que ce n'est pas la meilleure solution.
Mais c'est celle recommandée et qui est utilisée généralement.
Avec les plus courants: autotools et gcc.
Les autotools sont beaucoup décriés, un certain nombre de projets s'en écartent.
Oui, mais ce sont les plus utilisés. Et c'est le système le plus pratique actuellement pour les développeurs.
Mais j'ai déjà installé des projets utilisant les autotools qui mettaient un rpath correct.
Je suis intéressé de savoir. Lesquels?
J'en ai même vu qui refaisaient le link entre le make check et le make install parce que le rpath à utiliser n'était pas le même dans les deux cas.
Le "make check" des bibliothèques (utilisation de libtool) fait déjà un certain nombre de bidouilles (qui ne marchent pas partout) pour linker avec la bibliothèque compilée au lieu de la bibliothèque éventuellement installée (e.g. précédente version).
A noter que gcc est assez pénible à ne pas fournir par défaut des specs qui ajoutent au rpath l'emplacement de la libgcc_s.
Oui.
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
Mais il y a toujours la base du chemin à configurer quelque part.
Ben non, la base du chemin c'est $ORIGIN, ie la position de l'objet dans lequel est indiqué ce rpath. Le seul gag possible c'est le hardlink.
Mais cette position, il faut bien l'indiquer quelque part.
Dans l'article <484039d8$0$19312$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080530020839$:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de machines et qu'on veut installer telle ou telle bibliothèque pour soi, on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Dans l'article <484039d8$0$19312$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080530020839$301b@prunille.vinc17.org>:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de
machines et qu'on veut installer telle ou telle bibliothèque pour soi,
on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Dans l'article <484039d8$0$19312$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080530020839$:
Non, ce n'est pas rare. Dès qu'on est dans un labo avec un réseau de machines et qu'on veut installer telle ou telle bibliothèque pour soi, on est bien obligé de l'installer quelque part dans son home.
L'utilisation normale serait de demander à l'administrateur de l'installer.
Vincent Lefevre wrote in message <20080531081559$:
Mais c'est celle recommandée et qui est utilisée généralement.
Recommandée par qui ?
Mais cette position, il faut bien l'indiquer quelque part.
Je crois que tu n'as pas bien compris la sémantique de $ORIGIN. Relis le message de Marc plus attentivement.
Vincent Lefevre
Dans l'article <48413382$0$31892$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080531081559$:
Mais c'est celle recommandée et qui est utilisée généralement.
Recommandée par qui ?
Par les développeurs des logiciels en question. Il y a généralement un fichier INSTALL qui indique: configure, make, make install, avec éventuellement des options pour configure (cf configure --help). Il y a d'ailleurs un fichier INSTALL type qui est distribué avec les autotools (et utilisé quand on fait un autoreconf et que le fichier INSTALL est initialement absent). Tu noteras aussi qu'il n'y est fait aucune mention du run path.
Mais cette position, il faut bien l'indiquer quelque part.
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?).
Dans l'article <48413382$0$31892$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080531081559$5d5d@prunille.vinc17.org>:
Mais c'est celle recommandée et qui est utilisée généralement.
Recommandée par qui ?
Par les développeurs des logiciels en question. Il y a généralement
un fichier INSTALL qui indique: configure, make, make install, avec
éventuellement des options pour configure (cf configure --help). Il
y a d'ailleurs un fichier INSTALL type qui est distribué avec les
autotools (et utilisé quand on fait un autoreconf et que le fichier
INSTALL est initialement absent). Tu noteras aussi qu'il n'y est
fait aucune mention du run path.
Mais cette position, il faut bien l'indiquer quelque part.
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?).
Dans l'article <48413382$0$31892$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080531081559$:
Mais c'est celle recommandée et qui est utilisée généralement.
Recommandée par qui ?
Par les développeurs des logiciels en question. Il y a généralement un fichier INSTALL qui indique: configure, make, make install, avec éventuellement des options pour configure (cf configure --help). Il y a d'ailleurs un fichier INSTALL type qui est distribué avec les autotools (et utilisé quand on fait un autoreconf et que le fichier INSTALL est initialement absent). Tu noteras aussi qu'il n'y est fait aucune mention du run path.
Mais cette position, il faut bien l'indiquer quelque part.
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?).
Vincent Lefevre wrote in message <20080531152017$:
Par les développeurs des logiciels en question. Il y a généralement un fichier INSTALL qui indique: configure, make, make install, avec éventuellement des options pour configure (cf configure --help).
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.
Vincent Lefevre wrote in message
<20080531152017$5419@prunille.vinc17.org>:
Par les développeurs des logiciels en question. Il y a généralement
un fichier INSTALL qui indique: configure, make, make install, avec
éventuellement des options pour configure (cf configure --help).
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.
Vincent Lefevre wrote in message <20080531152017$:
Par les développeurs des logiciels en question. Il y a généralement un fichier INSTALL qui indique: configure, make, make install, avec éventuellement des options pour configure (cf configure --help).
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.
