ld.so(8) System Manager's Manual ld.so(8)
NOM
ld.so, ld-linux.so - Chargeur et editeur de liens dynamiques
SYNOPSIS
L'editeur de liens dynamiques peut etre lance indirectement en
demarrant un programme lie dynamiquement ou un objet partage (dans ce
cas, aucune option en ligne de commande ne peut etre transmise, et avec
ELF, l'editeur indique dans la section .interp du programme est
execute), ou directement en lancant :
/lib/ld-linux.so.* [OPTIONS] [PROGRAMME [ARGUMENTS]]
DESCRIPTION
Les programmes ld.so et ld-linux.so* trouvent et chargent les objets
partages (bibliotheques partagees) necessaires pour un programme,
preparent son demarrage et le lancent.
Les binaires Linux necessitent une edition de liens dynamiques (au
demarrage) sauf si l'option -static a ete indiquee sur la ligne de
commande de ld(1) durant la compilation.
Le programme ld.so traite les binaires a.out, un format utilise il y a
bien longtemps. Le programme ld-linux.so* (/lib/ld-linux.so.1 pour
libc5, /lib/ld-linux.so.2 pour glibc2) traite les binaires qui sont au
format ELF plus moderne. Les deux programmes ont le meme comportement
et utilisent les memes fichiers d'aide et memes programmes (ldd(1),
ldconfig(8) et /etc/ld.so.conf).
Lors de la resolution des dependances d'objets partages, l'editeur de
liens dynamiques inspecte d'abord chaque chaine de dependance a la
recherche d'une barre oblique (cela peut arriver si un chemin d'objet
partage contenant des barres obliques a ete indique au moment de la
liaison). Si une barre oblique est trouvee, alors la chaine de
dependance est interpretee comme un chemin (relatif ou absolu) et
l'objet partage est charge en utilisant ce chemin.
Si une dependance d'objet partage ne contient pas de barre oblique,
alors elle est recherchee dans l'ordre suivant :
(1) En utilisant les repertoires indiques dans l'attribut de la
section dynamique DT_RPATH du fichier binaire s'il est present et
si l'attribut DT_RUNPATH n'existe pas. L'utilisation de DT_RPATH
est deconseillee.
(2) En utilisant la variable d'environnement LD_LIBRARY_PATH, sauf si
l'executable est utilise dans le mode d'execution securisee
(consulter ci-dessous), auquel cas elle est ignoree.
(3) En utilisant les repertoires indiques dans l'attribut de la
section dynamique DT_RUNPATH du binaire s'il est present. De tels
repertoires sont recherches uniquement pour trouver ces objets
requis par les entrees DT_NEEDED (dependances directes) et ne
s'appliquent pas aux enfants des objets qui doivent eux-memes
avoir leurs propres entrees DT_RUNPATH. Cela est different de
DT_RPATH, qui est applique aux recherches pour tous les enfants
dans l'arbre de dependances.
(4) From the cache file /etc/ld.so.cache, which contains a compiled
list of candidate shared objects previously found in the augmented
library path. If, however, the binary was linked with the -z
nodefaultlib linker option, shared objects in the default paths
are skipped. Shared objects installed in hardware capability
directories (see below) are preferred to other shared objects.
(5) In the default path /lib, and then /usr/lib. (On some 64-bit
architectures, the default paths for 64-bit shared objects are
/lib64, and then /usr/lib64.) If the binary was linked with the
-z nodefaultlib linker option, this step is skipped.
Mots-cles de chaine dynamiques
Dans plusieurs emplacements, l'editeur de liens dynamiques developpe
les mots-cles de chaine dynamiques
- dans les variables d'environnement LD_LIBRARY_PATH, LD_PRELOAD et
LD_AUDIT ;
- dans les valeurs des mots-cles de la section dynamique DT_NEEDED,
DT_RPATH, DT_RUNPATH, DT_AUDIT et DT_DEPAUDIT des binaires ELF ;
- dans les arguments des options de ld.so dans la ligne de commande
--audit, --library-path et --preload (consulter ci-dessous) ;
- dans les arguments de nom de fichier pour les fonctions dlopen(3) et
dlmopen(3).
Les mots-cles substitues sont comme suit :
$ORIGIN (ou de maniere equivalente ${ORIGIN})
Cela developpe le repertoire contenant le programme ou l'objet
partage. Ainsi, une application situee dans un_repertoire/app
peut etre compilee avec
gcc -Wl,-rpath,'$ORIGIN/../lib'
de sorte qu'elle trouvera un objet partage associe dans
un_repertoire/lib ou que soit situe un_repertoire dans la
hierarchie de repertoires. Cela facilite la creation
d'applications << pretes a l'emploi >> qui n'ont pas besoin
d'etre installees dans un repertoire particulier mais peuvent au
contraire etre installees dans n'importe quel repertoire et
toujours trouver leurs propres objets partages.
$LIB (ou de maniere equivalente ${LIB})
Cela se developpe en lib ou lib64 en fonction de l'architecture
(par exemple lib64 pour x86-64 ou lib pour x86-32).
$PLATFORM (ou de maniere equivalente ${PLATFORM})
Cela se developpe en une chaine correspondant au type de
processeur du systeme hote (par exemple << x86_64 >>). Pour
certaines architectures, le noyau Linux ne fournit pas de chaine
de plateforme a l'editeur de liens dynamiques. La valeur de
cette chaine est issue de la valeur AT_PLATFORM du vecteur
auxiliaire (consulter getauxval(3)).
Remarquez que les mots-cles de chaine dynamiques doivent etre mis entre
parentheses correctement lorsqu'ils sont definis a partir de
l'interpreteur de commandes pour prevenir de leur developpement en tant
que variables de l'interpreteur ou d'environnement.
OPTIONS
--argv0 string (since glibc 2.33)
Set argv[0] to the value string before running the program.
--audit liste
Utiliser les objets nommes dans liste comme verificateurs. Les
objets sont delimites par des deux-points.
--glibc-hwcaps-mask list
only search built-in subdirectories if in list.
--glibc-hwcaps-prepend list
Search glibc-hwcaps subdirectories in list.
--inhibit-cache
Ne pas utiliser /etc/ld.so.cache.
--library-path chemin
Utiliser chemin au lieu du reglage de la variable
d'environnement LD_LIBRARY_PATH (consulter ci-dessous). Les
noms ORIGIN, LIB et PLATFORM sont interpretes comme pour la
variable d'environnement LD_LIBRARY_PATH.
--inhibit-rpath liste
Ignorer les informations de RPATH et RUNPATH dans les noms
d'objet dans liste. Cette option est ignoree dans le mode
d'execution securisee (voir ci-dessous). Les objets dans liste
sont separes par des deux-points ou des espaces.
--list Lister les dependances et la maniere de les resoudre.
--list-diagnostics (since glibc 2.33)
Print system diagnostic information in a machine-readable
format, such as some internal loader variables, the auxiliary
vector (see getauxval(3)), and the environment variables. On
some architectures, the command might print additional
information (like the cpu features used in GNU indirect function
selection on x86). --list-tunables (since glibc 2.33) Print
the names and values of all tunables, along with the minimum and
maximum allowed values.
--preload liste (depuis la glibc 2.30)
Precharger les objets indiques dans liste. Ces objets sont
delimites par des deux-points ou des espaces. Les objets sont
precharges comme c'est explique dans la description de la
variable d'environnement LD_PRELOAD ci-dessous.
Au contraire avec LD_PRELOAD, l'option --preload fournit une
facon de realiser le prechargement pour un executable unique
sans affecter le prechargement realise par un processus enfant
qui execute un nouveau programme.
--verify
Verifier que le programme est lie dynamiquement et que l'editeur
de liens peut le traiter.
ENVIRONNEMENT
Diverses variables d'environnement influencent les operations de
l'editeur de liens dynamiques.
Mode d'execution securisee
For security reasons, if the dynamic linker determines that a binary
should be run in secure-execution mode, the effects of some environment
variables are voided or modified, and furthermore those environment
variables are stripped from the environment, so that the program does
not even see the definitions. Some of these environment variables
affect the operation of the dynamic linker itself, and are described
below. Other environment variables treated in this way include:
GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN, LD_AUDIT, LD_DEBUG,
LD_DEBUG_OUTPUT, LD_DYNAMIC_WEAK, LD_HWCAP_MASK, LD_LIBRARY_PATH,
LD_ORIGIN_PATH, LD_PRELOAD, LD_PROFILE, LD_SHOW_AUXV, LOCALDOMAIN,
LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF,
RES_OPTIONS, TMPDIR, and TZDIR.
Un binaire est execute dans le mode d'execution securisee si l'entree
AT_SECURE dans le vecteur auxiliaire (consulter getauxval(3)) a une
valeur differente de zero. Cette entree peut avoir une valeur
differente de zero pour differentes raisons, dont :
- Les ID utilisateur reels et effectifs du processus different ou les
ID de groupe reels et effectifs different. Cela se produit
classiquement lors de l'execution d'un programme set-user-ID ou
set-group-ID ;
- Un processus avec un ID utilisateur non superutilisateur a execute
un binaire qui conferait des capacites au processus ;
- Une valeur differente de zero pouvait avoir ete reglee par un module
de securite de Linux.
Variables d'environnement
Parmi les variables d'environnement importantes, on trouve :
LD_ASSUME_KERNEL (from glibc 2.2.3 to glibc 2.36)
Each shared object can inform the dynamic linker of the minimum
kernel ABI version that it requires. (This requirement is
encoded in an ELF note section that is viewable via readelf -n
as a section labeled NT_GNU_ABI_TAG.) At run time, the dynamic
linker determines the ABI version of the running kernel and will
reject loading shared objects that specify minimum ABI versions
that exceed that ABI version.
LD_ASSUME_KERNEL peut etre utilise afin que l'editeur de liens
dynamiques considere qu'il est execute sur un systeme disposant
d'une version differente de l'ABI du noyau. Par exemple, la
commande suivante permet de considerer la version 2.2.5 du noyau
Linux lors du chargement des objets partages utilises par
monprogamme:
$ LD_ASSUME_KERNEL=2.2.5 ./monprogamme
Lorsque plusieurs versions d'un meme objet partage (dans des
repertoires differents du chemin de recherche) specifient des
versions minimales d'ABI du noyau differentes, LD_ASSUME_KERNEL
permet de selectionner la version de l'objet a utiliser (ce qui
depend de l'ordre de recherche des repertoires).
Historiquement, LD_ASSUME_KERNEL etait surtout utilisee pour
selectionner l'ancienne mise en oeuvre des threads POSIX par
LinuxThreads sur les systemes fournissant LinuxThreads et NPTL
(ce dernier etant generalement active par defaut) ; consulter
pthreads(7).
LD_BIND_NOW (depuis la glibc 2.1.1)
Si la chaine est non vide, l'editeur de liens resoudra tous les
symboles au demarrage du programme plutot que repousser la
resolution des noms de fonctions au moment ou elles sont
referencees en premier. Cela est utile dans un debogueur.
LD_LIBRARY_PATH
Une liste de repertoires dans lesquels chercher les
bibliotheques ELF au moment de l'execution. Les elements de la
liste sont separes par des deux-points ou des points-virgules et
il n'existe aussi aucune protection des separateurs. Un nom de
repertoire de longueur nulle indique le repertoire de travail en
cours.
Cette variable est ignoree dans le mode d'execution securisee.
A l'interieur des noms de chemin indiques dans LD_LIBRARY_PATH,
l'editeur de liens dynamiques developpe les mots-cles $ORIGIN,
$LIB et $PLATFORM (ou les versions utilisant des accolades
autour des noms) comme cela est decrit ci-dessus dans Mots-cles
de chaine dynamiques. Par consequent, par exemple, ce qui suit
provoquera la recherche d'une bibliotheque dans les
sous-repertoires lib ou lib64 en dessous du repertoire contenant
le programme a executer :
$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog
Remarquez l'utilisation de guillemets simples empechant le
developpement de $ORIGIN et $LIB en tant que variables
d'interpreteur.
LD_PRELOAD
Une liste complementaire, specifiee par l'utilisateur, d'objets
partages ELF a charger avant tous les autres objets. Cela permet
de surcharger selectivement les fonctions dans les autres objets
partages.
Les elements de la liste peuvent etre separes par des
deux-points ou des espaces et il n'existe aussi aucune
protection des separateurs. Les objets sont recherches en
utilisant les regles precisees dans DESCRIPTION et sont ajoutes
dans le mappage de liens dans l'ordre de droite a gauche indique
dans la liste.
Dans le mode d'execution securisee, le prechargement de noms de
chemin contenant des barres obliques est ignore. Par ailleurs,
les objets partages sont precharges seulement a partir des
repertoires de recherche standard et seulement si le bit de mode
set-user-ID est active (ce qui n'est pas habituel).
A l'interieur des noms indiques dans LD_PRELOAD, l'editeur de
liens dynamiques developpe les mots-cles $ORIGIN, $LIB et
$PLATFORM (ou les versions utilisant des accolades autour des
noms) comme cela est decrit ci-dessus dans Mots-cles de chaine
dynamiques. (Voir aussi le point sur la mise entre parentheses
dans la description de LD_LIBRARY_PATH.)
Il existe diverses methodes pour preciser les bibliotheques a
precharger, et celles-ci sont gerees dans l'ordre suivant :
(1) La variable d'environnement LD_PRELOAD.
(2) L'option --preload de ligne de commande lors de
l'invocation directe de l'editeur de liens dynamiques.
(3) Le fichier /etc/ld.so.preload (decrit ci-dessous).
LD_TRACE_LOADED_OBJECTS
Si la chaine est non vide, le programme liste ses dependances
dynamiques comme s'il etait lance par ldd(1), au lieu du
lancement normal.
Il existe de nombreuses autres variables plus ou moins obscures,
certaines obsoletes ou reservees pour un usage interne.
LD_AUDIT (depuis la glibc 2.4)
Une liste d'objets partages ELF specifies par l'utilisateur a
charger avant tous les autres a l'interieur d'un espace distinct
de nommage de l'editeur de liens (c'est-a-dire qu'il n'y aura
pas d'interference avec les liaisons sur les symboles normaux
qui auront lieu pendant le processus). Ces objets peuvent etre
utilises pour controler les operations effectuees par l'editeur
de liens dynamiques. Les elements de la liste sont separes par
des deux-points et il n'existe aucune protection des
separateurs.
LD_AUDIT est ignoree dans le mode d'execution securisee.
The dynamic linker will notify the audit shared objects at
so-called auditing checkpoints--for example, loading a new
shared object, resolving a symbol, or calling a symbol from
another shared object--by calling an appropriate function within
the audit shared object. For details, see rtld-audit(7). The
auditing interface is largely compatible with that provided on
Solaris, as described in its Linker and Libraries Guide, in the
chapter Runtime Linker Auditing Interface.
A l'interieur des noms indiques dans LD_AUDIT, l'editeur de
liens dynamiques developpe les mots-cles $ORIGIN, $LIB et
$PLATFORM (ou les versions utilisant des accolades autour des
noms) comme cela est decrit ci-dessus dans Mots-cles de chaine
dynamiques. (Voir aussi le point sur la mise entre parentheses
dans la description de LD_LIBRARY_PATH.)
Depuis la glibc 2.13, dans le mode d'execution securisee, les
noms dans la liste de controle contenant des barres obliques
sont ignores et seulement les objets partages des repertoires de
recherche standard ayant le bit de mode set-user-ID active sont
charges.
LD_BIND_NOT (depuis la glibc 2.1.95)
Si cette variable d'environnement est reglee a une valeur non
vide, ne pas mettre a jour les tables GOT (global offset table)
et PLT (procedure linkage table) apres la resolution d'un
symbole de fonction. En combinant l'utilisation de cette
variable avec LD_DEBUG (avec les categories bindings et
symbols), les liaisons de fonctions d'execution peuvent etre
observees.
LD_DEBUG (depuis la glibc 2.1)
Produire une information detaillee de debogage dans l'editeur de
liens dynamiques. Le contenu de cette variable est composee
d'une ou de plusieurs des categories suivantes, separees par des
deux-points, des virgules ou (si la valeur est entre guillemets)
par des espaces :
help Indiquer help dans la valeur de cette variable fait
que le programme n'est pas execute et qu'un message
est affiche sur les categories pouvant etre
indiquees dans cette variable d'environnement.
all Afficher toutes les informations de debogage
(exceptees statistics et unused ; consulter
ci-dessous).
bindings Afficher des informations sur la definition a
laquelle chaque symbole est lie.
files Afficher l'avancement pour le fichier d'entree.
libs Afficher les chemins de recherche de bibliotheque.
reloc Afficher le traitement de relocalisation
scopes Afficher des informations de portee.
statistics Afficher des statistiques de relocalisation.
symbols Afficher les chemins de recherche pour chaque
consultation de symbole.
unused Identifier les objets partages dynamiques non
utilises.
versions Afficher les dependances de version.
Depuis la glibc 2.3.4, LD_DEBUG est ignoree dans le mode
d'execution securisee a moins que le fichier /etc/suid-debug
existe (le contenu du fichier est non pertinent).
LD_DEBUG_OUTPUT (depuis la glibc 2.1)
Par defaut, la sortie de LD_DEBUG est ecrite sur la sortie
d'erreur standard. Si LD_DEBUG_OUTPUT est definie, alors la
sortie est ecrite selon le chemin defini dans sa valeur avec le
suffixe << . >> (point) suivi par l'ID du processus ajoute au
chemin.
LD_DEBUG_OUTPUT est ignoree dans le mode d'execution securisee.
LD_DYNAMIC_WEAK (depuis la glibc 2.1.91)
Par defaut, lors de la recherche de bibliotheques partagees pour
resoudre une reference de symbole, l'editeur de liens dynamiques
resoudra la premiere definition qu'il trouvera.
Old glibc versions (before glibc 2.2), provided a different
behavior: if the linker found a symbol that was weak, it would
remember that symbol and keep searching in the remaining shared
libraries. If it subsequently found a strong definition of the
same symbol, then it would instead use that definition. (If no
further symbol was found, then the dynamic linker would use the
weak symbol that it initially found.)
L'ancien comportement de la glibc n'etait pas normalise. (La
pratique normalisee consiste a ce que la distinction entre les
symboles faibles et forts intervient seulement au moment de la
liaison statique.) Dans la glibc 2.2, l'editeur de liens
dynamiques a ete modifie pour fournir le comportement actuel
(qui etait le comportement fourni par la plupart des autres
implementations a ce moment la).
Definir la variable d'environnement LD_DYNAMIC_WEAK (a n'importe
quelle valeur) conduit a l'ancien comportement de la glibc non
normalise, selon lequel un symbole faible dans une bibliotheque
partagee peut etre ecrase par un symbole fort trouve
ulterieurement dans une autre bibliotheque partagee. Remarquez
que meme si cette variable est definie, un symbole fort dans une
bibliotheque partagee n'ecrasera pas une definition faible du
meme symbole dans le programme principal.)
Depuis la glibc 2.3.4, LD_DYNAMIC_WEAK est ignoree dans le mode
d'execution securisee.
LD_HWCAP_MASK (from glibc 2.1 to glibc 2.38)
Mask for hardware capabilities. Since glibc 2.26, the option
might be ignored if glibc does not support tunables.
LD_ORIGIN_PATH (depuis la glibc 2.1)
Chemin ou le binaire est trouve.
Depuis la glibc 2.4, LD_ORIGIN_PATH est ignoree dans le mode
d'execution securisee.
LD_POINTER_GUARD (from glibc 2.4 to glibc 2.22)
Mettre a zero pour supprimer la protection sur les pointeurs.
Toute autre valeur active cette protection, ce qui est le
comportement par defaut. La protection sur les pointeurs est un
mecanisme de securite ou certains pointeurs vers du code stocke
dans la zone memoire accessible en ecriture (comme les adresses
de retour conservees par setjmp(3), ou des pointeurs de
fonctions utilises par diverses fonctions internes de glibc)
sont modifies semi-aleatoirement pour rendre plus difficile une
utilisation malveillante par un intrus, qui utiliserait par
exemple un depassement de tampon ou de la pile. Depuis la
glibc 2.23, LD_POINTER_GUARD ne peut plus etre utilisee pour
desactiver cette protection, qui est toujours activee.
LD_PROFILE (depuis la glibc 2.1)
The name of a (single) shared object to be profiled, specified
either as a pathname or a soname. Profiling output is appended
to the file whose name is: $LD_PROFILE_OUTPUT/
$LD_PROFILE.profile.
Since glibc 2.2.5, LD_PROFILE uses a different default path in
secure-execution mode.
LD_PROFILE_OUTPUT (depuis la glibc 2.1)
Repertoire ou sera ecrit le resultat de LD_PROFILE. Si cette
variable n'est pas definie, ou si elle est definie a une valeur
vide, le defaut est /var/tmp.
LD_PROFILE_OUTPUT is ignored in secure-execution mode; instead
/var/profile is always used.
LD_SHOW_AUXV (depuis la glibc 2.1)
Si cette variable d'environnement est definie (a n'importe
quelle valeur), afficher le tableau auxiliaire transmis a partir
du noyau (consulter aussi getauxval(3)).
Depuis la glibc 2.3.4, LD_SHOW_AUXV est ignoree dans le mode
d'execution securisee.
LD_TRACE_PRELINKING (from glibc 2.4 to glibc 2.35)
Si cette variable d'environnement est definie, tracer la
pre-liaison de l'objet dont le nom est assigne a cette variable
d'environnement. (Utiliser ldd(1) pour obtenir une liste des
objets pouvant etre traces.) Si le nom d'objet n'est pas
reconnu, alors l'activite de pre-liaison est tracee.
LD_USE_LOAD_BIAS (from glibc 2.3.3 to glibc 2.35)
Par defaut, c'est-a-dire si cette variable n'est pas definie,
les executables et les objets partages pre-lies (prelink)
respectent les adresses de base des objets partages dont ils
dependent, alors que les executables PIE (position-independent
executables) non pre-lies et les autres objets partages ne les
respectent pas. Si LD_USE_LOAD_BIAS est definie a la valeur 1,
les executables et les PIE vont respecter les adresses de base.
Si LD_USE_LOAD_BIAS est definie a 0, ni les executables, ni les
PIE ne respecteront les adresses de base.
Depuis la glibc 2.3.3, cette variable est ignoree dans le mode
d'execution securisee.
LD_VERBOSE (depuis la glibc 2.1)
S'il s'agit d'une chaine non vide, afficher les informations sur
la version des symboles du programme si la variable
d'environnement LD_TRACE_LOADED_OBJECTS a ete definie.
LD_WARN (depuis la glibc 2.1.3)
Si la chaine est non vide, avertir si un symbole n'est pas
resolu.
LD_PREFER_MAP_32BIT_EXEC (x86-64 seulement ; depuis la glibc 2.23)
Selon le guide d'optimisation logicielle de Silvermont d'Intel,
pour les applications 64 bits, les performances de prediction de
branchement peuvent etre deteriorees quand la cible d'un
branchement est situee a plus de 4 GB du branchement. Si cette
variable d'environnement est definie (a n'importe quelle
valeur), l'editeur de liens dynamiques essaie de mapper les
pages d'executables en utilisant l'indicateur MAP_32BIT de
mmap(2) et de revenir a un mappage sans cet indicateur si cet
essai echoue. NB : MAP_32BIT mappera avec les 2 GB bas (pas
4 GB) de l'espace d'adressage.
Parce que MAP_32BIT reduit l'eventail d'adressage pour la
distribution aleatoire de l'espace d'adressage (ASLR),
LD_PREFER_MAP_32BIT_EXEC est toujours desactivee dans le mode
d'execution securisee.
FICHIERS
/lib/ld.so
Le chargeur et editeur de liens dynamiques a.out.
/lib/ld-linux.so.{1,2}
Le chargeur et editeur de liens dynamiques ELF.
/etc/ld.so.cache
Fichier contenant la liste compilee des repertoires dans
lesquels rechercher les objets partages et une liste d'objets
partages candidats. Consulter ldconfig(8).
/etc/ld.so.preload
Fichier contenant une liste d'objets partages ELF, separes par
des virgules, a charger avant le programme. Consultez le point a
propos de LD_PRELOAD ci-dessus. Si LD_PRELOAD et
/etc/ld.so.preload sont employes, la bibliotheque indiquee par
LD_PRELOAD est prechargee en premier. /etc/ld.so.preload a un
effet sur tout le systeme, faisant que les bibliotheques
indiquees sont prechargees pour tous les programmes executes sur
le systeme. (Cela est habituellement indesirable et employe
uniquement comme remede d'urgence, par exemple, comme
contournement temporaire d'un probleme de mauvaise configuration
de bibliotheque.)
lib*.so*
Objets partages.
NOTES
Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37)
Certains objets partages sont compiles en utilisant des instructions
specifiques au materiel qui n'existent pas sur tous les processeurs.
Ces objets devraient etre installes dans des repertoires dont les noms
definissent les capacites materielles necessaires, comme
/usr/lib/sse2/. L'editeur de liens dynamiques compare ces repertoires
au materiel de la machine et selectionne la version la mieux adaptee
pour un objet partage donne. Les repertoires de capacite materielle
peuvent etre imbriques pour combiner les caracteristiques du
microprocesseur. La liste des noms de capacite materielle pris en
charge depend du microprocesseur. Les noms suivants sont reconnus pour
le moment.
Alpha ev4, ev5, ev56, ev6, ev67
MIPS loongson2e, loongson2f, octeon, octeon2
PowerPC
4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp,
efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4,
power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe,
ucache, vsx
SPARC flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
s390 dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa,
stfle, z900, z990, z9-109, z10, zarch
x86 (32 bits seulement)
acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586,
i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse,
sse2, tm
The legacy hardware capabilities support has the drawback that each new
feature added grows the search path exponentially, because it has to be
added to every combination of the other existing features.
For instance, on x86 32-bit, if the hardware supports i686 and sse2,
the resulting search path will be i686/sse2:i686:sse2:.. A new
capability newcap will set the search path to
newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:.
glibc Hardware capabilities (from glibc 2.33)
glibc 2.33 added a new hardware capability scheme,
where under each CPU architecture, certain levels can be
defined, grouping support for certain features or special
instructions. Each architecture level has a fixed set of paths
that it adds to the dynamic linker search list, depending on the
hardware of the machine. Since each new architecture level is
not combined with previously existing ones, the new scheme does
not have the drawback of growing the dynamic linker search list
uncontrollably.
For instance, on x86 64-bit, if the hardware supports x86_64-v3 (for
instance Intel Haswell or AMD Excavator), the resulting search path
will be glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. The following
paths are currently supported, in priority order.
PowerPC (64-bit little-endian only)
power10, power9
s390 (64-bit only)
z16, z15, z14, z13
x86 (64-bit only)
x86-64-v4, x86-64-v3, x86-64-v2
glibc 2.37 removed support for the legacy hardware capabilities.
VOIR AUSSI
ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5),
capabilities(7), rtld-audit(7), ldconfig(8), sln(8)
TRADUCTION
La traduction francaise de cette page de manuel a ete creee par
Christophe Blaess , Stephan Rafin
, Thierry Vignaud ,
Francois Micaux, Alain Portal , Jean-Philippe
Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas
Huriaux , Nicolas Francois
, Florentin Duneau
, Simon Paillard , Denis Barbier , David Prevot
et Jean-Paul Guillonneau
Cette traduction est une documentation libre ; veuillez vous reporter a
la GNU General Public License version 3
concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE.
Si vous decouvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message a .
Pages du manuel de Linux 6.06 12 fevrier 2024 ld.so(8)