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
Si c'est le cas, il y a eu un loupé dans le passage solaris -> linux. Sous solaris, c'est uname -i (qui malheureusement sous linux semble renvoyer de façon assez uniforme : unknown).
Sous linux, pour sélectionner suivant les features supportées (ressemble au $ISALIST de solaris, mais plus large, et automatique), on met les bibliothèques dans un sous-repertoire tls/i686/sse2/cmov (par exemple) du répertoire indiqué par ld.so.conf ou rpath ou LD_LIBRARY_PATH.
Stephane CHAZELAS wrote:
Moi j'y lis mention de $PLATFORM.
[...]
Ca ressemble a uname -m
Si c'est le cas, il y a eu un loupé dans le passage solaris -> linux.
Sous solaris, c'est uname -i (qui malheureusement sous linux semble
renvoyer de façon assez uniforme : unknown).
Sous linux, pour sélectionner suivant les features supportées (ressemble
au $ISALIST de solaris, mais plus large, et automatique), on met les
bibliothèques dans un sous-repertoire tls/i686/sse2/cmov (par exemple) du
répertoire indiqué par ld.so.conf ou rpath ou LD_LIBRARY_PATH.
Si c'est le cas, il y a eu un loupé dans le passage solaris -> linux. Sous solaris, c'est uname -i (qui malheureusement sous linux semble renvoyer de façon assez uniforme : unknown).
Sous linux, pour sélectionner suivant les features supportées (ressemble au $ISALIST de solaris, mais plus large, et automatique), on met les bibliothèques dans un sous-repertoire tls/i686/sse2/cmov (par exemple) du répertoire indiqué par ld.so.conf ou rpath ou LD_LIBRARY_PATH.
Vincent Lefevre
Dans l'article <g210as$9al$, Marc écrit:
Stephane CHAZELAS wrote:
Moi j'y lis mention de $PLATFORM. [...]
Ca ressemble a uname -m
Si c'est le cas, il y a eu un loupé dans le passage solaris -> linux. Sous solaris, c'est uname -i (qui malheureusement sous linux semble renvoyer de façon assez uniforme : unknown).
Effectivement, une véritable valeur donnant une information utile sur le hardware serait préférable.
Sous linux, pour sélectionner suivant les features supportées (ressemble au $ISALIST de solaris, mais plus large, et automatique), on met les bibliothèques dans un sous-repertoire tls/i686/sse2/cmov (par exemple) du répertoire indiqué par ld.so.conf ou rpath ou LD_LIBRARY_PATH.
Sur ma machine Linux/x86_64, ce genre de chose ne semble pas fonctionner: un strace indique que les sous-répertoires suivants sont essayés pour chaque chemin: _ tls/x86_64 _ tls _ x86_64 _ . i.e. pas de possibilité de distinguer les différents types de x86_64.
Dans l'article <g210as$9al$1@nef.ens.fr>,
Marc <marc.glisse@gmail.com> écrit:
Stephane CHAZELAS wrote:
Moi j'y lis mention de $PLATFORM.
[...]
Ca ressemble a uname -m
Si c'est le cas, il y a eu un loupé dans le passage solaris -> linux.
Sous solaris, c'est uname -i (qui malheureusement sous linux semble
renvoyer de façon assez uniforme : unknown).
Effectivement, une véritable valeur donnant une information utile
sur le hardware serait préférable.
Sous linux, pour sélectionner suivant les features supportées (ressemble
au $ISALIST de solaris, mais plus large, et automatique), on met les
bibliothèques dans un sous-repertoire tls/i686/sse2/cmov (par exemple) du
répertoire indiqué par ld.so.conf ou rpath ou LD_LIBRARY_PATH.
Sur ma machine Linux/x86_64, ce genre de chose ne semble pas
fonctionner: un strace indique que les sous-répertoires suivants
sont essayés pour chaque chemin:
_ tls/x86_64
_ tls
_ x86_64
_ .
i.e. pas de possibilité de distinguer les différents types de x86_64.
Si c'est le cas, il y a eu un loupé dans le passage solaris -> linux. Sous solaris, c'est uname -i (qui malheureusement sous linux semble renvoyer de façon assez uniforme : unknown).
Effectivement, une véritable valeur donnant une information utile sur le hardware serait préférable.
Sous linux, pour sélectionner suivant les features supportées (ressemble au $ISALIST de solaris, mais plus large, et automatique), on met les bibliothèques dans un sous-repertoire tls/i686/sse2/cmov (par exemple) du répertoire indiqué par ld.so.conf ou rpath ou LD_LIBRARY_PATH.
Sur ma machine Linux/x86_64, ce genre de chose ne semble pas fonctionner: un strace indique que les sous-répertoires suivants sont essayés pour chaque chemin: _ tls/x86_64 _ tls _ x86_64 _ . i.e. pas de possibilité de distinguer les différents types de x86_64.
Vincent Lefevre wrote in message <20080602175017$:
i.e. pas de possibilité de distinguer les différents types de x86_64.
Sauf erreur de ma part, il n'y a pas encore, du point de vue de gcc, différents types de x86_64. Ce qui peux expliquer des choses.
Vincent Lefevre
Dans l'article <48443663$0$24614$, Nicolas George <nicolas$ écrit:
Sauf erreur de ma part, il n'y a pas encore, du point de vue de gcc, différents types de x86_64. Ce qui peux expliquer des choses.
Je ne sais pas ce que tu entends exactement par là, mais la page man de gcc 4.2.3 indique:
Intel 386 and AMD x86-64 Options
These -m options are defined for the i386 and x86-64 family of computers: [...] nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. [...] k8, opteron, athlon64, athlon-fx AMD K8 core based CPUs with x86-64 instruction set support.
Ça fait au moins deux (et il y en a encore plus dans la doc de GCC 4.3).
Dans l'article <48443663$0$24614$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Sauf erreur de ma part, il n'y a pas encore, du point de vue de gcc,
différents types de x86_64. Ce qui peux expliquer des choses.
Je ne sais pas ce que tu entends exactement par là, mais la page man
de gcc 4.2.3 indique:
Intel 386 and AMD x86-64 Options
These -m options are defined for the i386 and x86-64 family of
computers:
[...]
nocona
Improved version of Intel Pentium4 CPU with 64-bit extensions,
MMX, SSE, SSE2 and SSE3 instruction set support.
[...]
k8, opteron, athlon64, athlon-fx
AMD K8 core based CPUs with x86-64 instruction set support.
Ça fait au moins deux (et il y en a encore plus dans la doc de GCC 4.3).
Dans l'article <48443663$0$24614$, Nicolas George <nicolas$ écrit:
Sauf erreur de ma part, il n'y a pas encore, du point de vue de gcc, différents types de x86_64. Ce qui peux expliquer des choses.
Je ne sais pas ce que tu entends exactement par là, mais la page man de gcc 4.2.3 indique:
Intel 386 and AMD x86-64 Options
These -m options are defined for the i386 and x86-64 family of computers: [...] nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. [...] k8, opteron, athlon64, athlon-fx AMD K8 core based CPUs with x86-64 instruction set support.
Ça fait au moins deux (et il y en a encore plus dans la doc de GCC 4.3).
