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
Vincent Lefevre wrote in message <20080529004912$:
Il stocke le chemin complet vers la bibliothèque (pas uniquement le leafname); c'est le format Mach-O.
Ce qui est, à mon avis, une immense connerie. Comme de hardcoder le chemin vers les commandes dans un programme.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Normal : sur un système correctement configuré, la plupart du temps il n'y en a pas besoin, pas plus que de LD_LIBRARY_PATH : ld.so sait où trouver les bibliothèques installées sur le système et les charge directement.
Quand ce n'est pas le cas, il y a moyen de configurer, même si c'est un peu technique.
Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...), il n'est à ma connaissance généralement pas possible de spécifier le nouvel emplacement par une variable d'environnement; bon, en fait, ça dépend du Linux: avec certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le run path (que c'est bordélique...).
Même si le RPATH a la priorité sur les variables d'environnement (ce que je trouve une erreur, soit dit en passant), si la bibliothèque originale n'existe plus, LD_LIBRARY_PATH est utilisé pour la rechercher, donc en cas de déplacement, ce n'est pas un problème.
D'autre part, le rpath est global pour toutes les bibliothèques, ce qui exclut certains combinaisons (ceci dit, en pratique, ces combinaisons ne devraient jamais arriver).
Comme tu le dis, c'est une situation particulièrement tordue et improbable qui demande ça, et dans une telle situation, on peut vraissemblablement faire des concession. Par exemple regrouper des liens symboliques vers les bibliothèques requises dans un répertoire dédié.
Au final, je trouve le mécanisme ELF infiniment supérieur à ce que tu décris du mécanisme mach-0.
Vincent Lefevre wrote in message
<20080529004912$7eeb@prunille.vinc17.org>:
Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
Ce qui est, à mon avis, une immense connerie. Comme de hardcoder le chemin
vers les commandes dans un programme.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas
utilisé par défaut par les outils de compilation.
Normal : sur un système correctement configuré, la plupart du temps il n'y
en a pas besoin, pas plus que de LD_LIBRARY_PATH : ld.so sait où trouver les
bibliothèques installées sur le système et les charge directement.
Quand ce n'est pas le cas, il y a moyen de configurer, même si c'est un peu
technique.
Ensuite, s'il est
utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage
du home de l'utilisateur, ça arrive...), il n'est à ma connaissance
généralement pas possible de spécifier le nouvel emplacement par une
variable d'environnement; bon, en fait, ça dépend du Linux: avec
certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le
run path (que c'est bordélique...).
Même si le RPATH a la priorité sur les variables d'environnement (ce que je
trouve une erreur, soit dit en passant), si la bibliothèque originale
n'existe plus, LD_LIBRARY_PATH est utilisé pour la rechercher, donc en cas
de déplacement, ce n'est pas un problème.
D'autre part, le rpath est global
pour toutes les bibliothèques, ce qui exclut certains combinaisons
(ceci dit, en pratique, ces combinaisons ne devraient jamais arriver).
Comme tu le dis, c'est une situation particulièrement tordue et improbable
qui demande ça, et dans une telle situation, on peut vraissemblablement
faire des concession. Par exemple regrouper des liens symboliques vers les
bibliothèques requises dans un répertoire dédié.
Au final, je trouve le mécanisme ELF infiniment supérieur à ce que tu décris
du mécanisme mach-0.
Vincent Lefevre wrote in message <20080529004912$:
Il stocke le chemin complet vers la bibliothèque (pas uniquement le leafname); c'est le format Mach-O.
Ce qui est, à mon avis, une immense connerie. Comme de hardcoder le chemin vers les commandes dans un programme.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Normal : sur un système correctement configuré, la plupart du temps il n'y en a pas besoin, pas plus que de LD_LIBRARY_PATH : ld.so sait où trouver les bibliothèques installées sur le système et les charge directement.
Quand ce n'est pas le cas, il y a moyen de configurer, même si c'est un peu technique.
Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...), il n'est à ma connaissance généralement pas possible de spécifier le nouvel emplacement par une variable d'environnement; bon, en fait, ça dépend du Linux: avec certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le run path (que c'est bordélique...).
Même si le RPATH a la priorité sur les variables d'environnement (ce que je trouve une erreur, soit dit en passant), si la bibliothèque originale n'existe plus, LD_LIBRARY_PATH est utilisé pour la rechercher, donc en cas de déplacement, ce n'est pas un problème.
D'autre part, le rpath est global pour toutes les bibliothèques, ce qui exclut certains combinaisons (ceci dit, en pratique, ces combinaisons ne devraient jamais arriver).
Comme tu le dis, c'est une situation particulièrement tordue et improbable qui demande ça, et dans une telle situation, on peut vraissemblablement faire des concession. Par exemple regrouper des liens symboliques vers les bibliothèques requises dans un répertoire dédié.
Au final, je trouve le mécanisme ELF infiniment supérieur à ce que tu décris du mécanisme mach-0.
Nicolas George
Vincent Lefevre wrote in message <20080529010906$:
Cette fonctionnalité n'est pas utilisée par défaut.
Comme beaucoup de fonctionnalités qui traitent avec des situations rares. Le cas normal, c'est que les bibliothèques soient trouvées directement par ld.so, sans intervention supplémentaire.
Vincent Lefevre wrote in message
<20080529010906$7e97@prunille.vinc17.org>:
Cette fonctionnalité n'est pas utilisée par défaut.
Comme beaucoup de fonctionnalités qui traitent avec des situations rares. Le
cas normal, c'est que les bibliothèques soient trouvées directement par
ld.so, sans intervention supplémentaire.
Vincent Lefevre wrote in message <20080529010906$:
Cette fonctionnalité n'est pas utilisée par défaut.
Comme beaucoup de fonctionnalités qui traitent avec des situations rares. Le cas normal, c'est que les bibliothèques soient trouvées directement par ld.so, sans intervention supplémentaire.
Marc
Vincent Lefevre wrote:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique. Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point. Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
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.
On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Ça dépend lesquels...
Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...),
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
il n'est à ma connaissance généralement pas possible de spécifier le nouvel emplacement par une variable d'environnement; bon, en fait, ça dépend du Linux: avec certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le run path (que c'est bordélique...).
Oui il y a LD_LIBRARY_PATH. Sinon on peut aussi envisager d'éditer l'exécutable pour changer son rpath (tant que le nouveau rpath est plus court que l'ancien, c'est facile. Sinon c'est variable, le linker de solaris réserve depuis peu de la place pour pouvoir éditer la section dynamique des objets ELF, je ne sais pas si celui de gnu peut faire pareil).
Si les Mac stockent le chemin entier, ils ne sont pas bien avancés quand une bibliothèque bouge...
Freebsd (peut-être d'autres aussi) me semble le plus sympa, à permettre de remapper chaque bibliothèque individuellement selon l'application qui la demande.
Vincent Lefevre wrote:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point.
Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
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.
On peut tout aussi bien spécifier un rpath à la compilation, on peut
aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de
la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas
utilisé par défaut par les outils de compilation.
Ça dépend lesquels...
Ensuite, s'il est utilisé, alors en cas de déplacement des
bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...),
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
il n'est à ma connaissance
généralement pas possible de spécifier le nouvel emplacement par une
variable d'environnement; bon, en fait, ça dépend du Linux: avec
certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le
run path (que c'est bordélique...).
Oui il y a LD_LIBRARY_PATH. Sinon on peut aussi envisager d'éditer
l'exécutable pour changer son rpath (tant que le nouveau rpath est plus
court que l'ancien, c'est facile. Sinon c'est variable, le linker de
solaris réserve depuis peu de la place pour pouvoir éditer la section
dynamique des objets ELF, je ne sais pas si celui de gnu peut faire
pareil).
Si les Mac stockent le chemin entier, ils ne sont pas bien avancés quand
une bibliothèque bouge...
Freebsd (peut-être d'autres aussi) me semble le plus sympa, à permettre
de remapper chaque bibliothèque individuellement selon l'application qui
la demande.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique. Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point. Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
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.
On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Ça dépend lesquels...
Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...),
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
il n'est à ma connaissance généralement pas possible de spécifier le nouvel emplacement par une variable d'environnement; bon, en fait, ça dépend du Linux: avec certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le run path (que c'est bordélique...).
Oui il y a LD_LIBRARY_PATH. Sinon on peut aussi envisager d'éditer l'exécutable pour changer son rpath (tant que le nouveau rpath est plus court que l'ancien, c'est facile. Sinon c'est variable, le linker de solaris réserve depuis peu de la place pour pouvoir éditer la section dynamique des objets ELF, je ne sais pas si celui de gnu peut faire pareil).
Si les Mac stockent le chemin entier, ils ne sont pas bien avancés quand une bibliothèque bouge...
Freebsd (peut-être d'autres aussi) me semble le plus sympa, à permettre de remapper chaque bibliothèque individuellement selon l'application qui la demande.
Paul Gaborit
À (at) Thu, 29 May 2008 12:06:03 +0000 (UTC), Marc écrivait (wrote):
Freebsd (peut-être d'autres aussi) me semble le plus sympa, à permettre de remapper chaque bibliothèque individuellement selon l'application qui la demande.
Le fichier 'libmap.conf' 'est effectivement une chose que j'avais trouvé très puissante sur FreerBSD. Ça complète parfaitement l'arsenal des autres solutions finalement toutes un peu bancales.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 29 May 2008 12:06:03 +0000 (UTC),
Marc <marc.glisse@gmail.com> écrivait (wrote):
Freebsd (peut-être d'autres aussi) me semble le plus sympa, à permettre
de remapper chaque bibliothèque individuellement selon l'application qui
la demande.
Le fichier 'libmap.conf' 'est effectivement une chose que j'avais
trouvé très puissante sur FreerBSD. Ça complète parfaitement l'arsenal
des autres solutions finalement toutes un peu bancales.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 29 May 2008 12:06:03 +0000 (UTC), Marc écrivait (wrote):
Freebsd (peut-être d'autres aussi) me semble le plus sympa, à permettre de remapper chaque bibliothèque individuellement selon l'application qui la demande.
Le fichier 'libmap.conf' 'est effectivement une chose que j'avais trouvé très puissante sur FreerBSD. Ça complète parfaitement l'arsenal des autres solutions finalement toutes un peu bancales.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
mpg
Le (on) mercredi 28 mai 2008 19:59, Nicolas George a écrit (wrote) :
mais dans des versions différentes,
On se demande bien pourquoi.
Parce que c'est des youser. Et par définition, un youser, ça fait des choses
auxquelles le sysadmin ne s'attend pas, voire qui embêtent le sysadmin :-)
Manuel.
Le (on) mercredi 28 mai 2008 19:59, Nicolas George a écrit (wrote) :
mais dans des versions différentes,
On se demande bien pourquoi.
Parce que c'est des youser. Et par définition, un youser, ça fait des choses
auxquelles le sysadmin ne s'attend pas, voire qui embêtent le sysadmin :-)
Le (on) mercredi 28 mai 2008 19:59, Nicolas George a écrit (wrote) :
mais dans des versions différentes,
On se demande bien pourquoi.
Parce que c'est des youser. Et par définition, un youser, ça fait des choses
auxquelles le sysadmin ne s'attend pas, voire qui embêtent le sysadmin :-)
Manuel.
Vincent Lefevre
Dans l'article <483e55c3$0$17095$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080529004912$:
Il stocke le chemin complet vers la bibliothèque (pas uniquement le leafname); c'est le format Mach-O.
Ce qui est, à mon avis, une immense connerie. Comme de hardcoder le chemin vers les commandes dans un programme.
C'est ça ou le LD_LIBRARY_PATH.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Normal : sur un système correctement configuré, la plupart du temps il n'y en a pas besoin, pas plus que de LD_LIBRARY_PATH : ld.so sait où trouver les bibliothèques installées sur le système et les charge directement.
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).
Quand ce n'est pas le cas, il y a moyen de configurer, même si c'est un peu technique.
Mettre les home des utilisateurs dans le ld.so.conf serait un très gros trou de sécurité.
Même si le RPATH a la priorité sur les variables d'environnement (ce que je trouve une erreur, soit dit en passant), si la bibliothèque originale n'existe plus, LD_LIBRARY_PATH est utilisé pour la rechercher, donc en cas de déplacement, ce n'est pas un problème.
Ça ne résout pas le problème où on peut se retrouver avec des timeout NFS.
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.
Dans l'article <483e55c3$0$17095$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080529004912$7eeb@prunille.vinc17.org>:
Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
Ce qui est, à mon avis, une immense connerie. Comme de hardcoder le
chemin vers les commandes dans un programme.
C'est ça ou le LD_LIBRARY_PATH.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas
utilisé par défaut par les outils de compilation.
Normal : sur un système correctement configuré, la plupart du temps il n'y
en a pas besoin, pas plus que de LD_LIBRARY_PATH : ld.so sait où trouver les
bibliothèques installées sur le système et les charge directement.
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).
Quand ce n'est pas le cas, il y a moyen de configurer, même si c'est
un peu technique.
Mettre les home des utilisateurs dans le ld.so.conf serait un très
gros trou de sécurité.
Même si le RPATH a la priorité sur les variables d'environnement (ce
que je trouve une erreur, soit dit en passant), si la bibliothèque
originale n'existe plus, LD_LIBRARY_PATH est utilisé pour la
rechercher, donc en cas de déplacement, ce n'est pas un problème.
Ça ne résout pas le problème où on peut se retrouver avec des timeout
NFS.
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.
Dans l'article <483e55c3$0$17095$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080529004912$:
Il stocke le chemin complet vers la bibliothèque (pas uniquement le leafname); c'est le format Mach-O.
Ce qui est, à mon avis, une immense connerie. Comme de hardcoder le chemin vers les commandes dans un programme.
C'est ça ou le LD_LIBRARY_PATH.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Normal : sur un système correctement configuré, la plupart du temps il n'y en a pas besoin, pas plus que de LD_LIBRARY_PATH : ld.so sait où trouver les bibliothèques installées sur le système et les charge directement.
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).
Quand ce n'est pas le cas, il y a moyen de configurer, même si c'est un peu technique.
Mettre les home des utilisateurs dans le ld.so.conf serait un très gros trou de sécurité.
Même si le RPATH a la priorité sur les variables d'environnement (ce que je trouve une erreur, soit dit en passant), si la bibliothèque originale n'existe plus, LD_LIBRARY_PATH est utilisé pour la rechercher, donc en cas de déplacement, ce n'est pas un problème.
Ça ne résout pas le problème où on peut se retrouver avec des timeout NFS.
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.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique. Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point. Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
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).
On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Ça dépend lesquels...
Avec les plus courants: autotools et gcc.
Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...),
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
Mais il y a toujours la base du chemin à configurer quelque part. Et cf ci-dessus: ce n'est pas fait par défaut.
Si les Mac stockent le chemin entier, ils ne sont pas bien avancés quand une bibliothèque bouge...
Il y a des variables d'environnement pour donner les nouveaux chemins.
Dans l'article <g1m67b$158k$1@nef.ens.fr>,
Marc <marc.glisse@gmail.com> écrit:
Vincent Lefevre wrote:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point.
Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
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).
On peut tout aussi bien spécifier un rpath à la compilation, on peut
aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de
la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas
utilisé par défaut par les outils de compilation.
Ça dépend lesquels...
Avec les plus courants: autotools et gcc.
Ensuite, s'il est utilisé, alors en cas de déplacement des
bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...),
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
Mais il y a toujours la base du chemin à configurer quelque part.
Et cf ci-dessus: ce n'est pas fait par défaut.
Si les Mac stockent le chemin entier, ils ne sont pas bien avancés quand
une bibliothèque bouge...
Il y a des variables d'environnement pour donner les nouveaux chemins.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique. Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point. Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
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).
On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation.
Ça dépend lesquels...
Avec les plus courants: autotools et gcc.
Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...),
On peut utiliser des chemins relatifs dans un rpath avec $ORIGIN.
Mais il y a toujours la base du chemin à configurer quelque part. Et cf ci-dessus: ce n'est pas fait par défaut.
Si les Mac stockent le chemin entier, ils ne sont pas bien avancés quand une bibliothèque bouge...
Il y a des variables d'environnement pour donner les nouveaux chemins.
Dans l'article <483e55fa$0$17095$, Nicolas George <nicolas$ écrit:
Comme beaucoup de fonctionnalités qui traitent avec des situations rares.
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.
Dans l'article <483e55fa$0$17095$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Comme beaucoup de fonctionnalités qui traitent avec des situations rares.
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.
Dans l'article <483e55fa$0$17095$, Nicolas George <nicolas$ écrit:
Comme beaucoup de fonctionnalités qui traitent avec des situations rares.
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.
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.
Avec les plus courants: autotools et gcc.
Les autotools sont beaucoup décriés, un certain nombre de projets s'en écartent. Mais j'ai déjà installé des projets utilisant les autotools qui mettaient un rpath correct. 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. 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.
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.
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.
Avec les plus courants: autotools et gcc.
Les autotools sont beaucoup décriés, un certain nombre de projets s'en
écartent. Mais j'ai déjà installé des projets utilisant les autotools qui
mettaient un rpath correct. 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. 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.
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.
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.
Avec les plus courants: autotools et gcc.
Les autotools sont beaucoup décriés, un certain nombre de projets s'en écartent. Mais j'ai déjà installé des projets utilisant les autotools qui mettaient un rpath correct. 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. 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.
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.
