Provided by: manpages-fr_4.27.0-1_all 
NOM
ld.so, ld-linux.so - Chargeur et éditeur de liens dynamiques
SYNOPSIS
L'éditeur de liens dynamiques peut être lancé indirectement en démarrant un programme lié dynamiquement
ou un objet partagé (dans ce cas, aucune option en ligne de commande ne peut être transmise, et avec ELF,
l'éditeur indiqué dans la section .interp du programme est exécuté), ou directement en lançant :
/lib/ld-linux.so.* [OPTIONS] [PROGRAMME [ARGUMENTS]]
DESCRIPTION
Les programmes ld.so et ld-linux.so* trouvent et chargent les objets partagés (bibliothèques partagées)
nécessaires pour un programme, préparent son démarrage et le lancent.
Les binaires Linux nécessitent une édition de liens dynamiques (au démarrage) sauf si l'option -static a
été indiquée sur la ligne de commande de ld(1) durant la compilation.
Le programme ld.so traite les binaires a.out, un format utilisé 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 même comportement et utilisent les mêmes fichiers
d’aide et mêmes programmes (ldd(1), ldconfig(8) et /etc/ld.so.conf).
Lors de la résolution des dépendances d’objets partagés, l'éditeur de liens dynamiques inspecte d'abord
chaque chaîne de dépendance à la recherche d'une barre oblique (cela peut arriver si un chemin d’objet
partagé contenant des barres obliques a été indiqué au moment de la liaison). Si une barre oblique est
trouvée, alors la chaîne de dépendance est interprétée comme un chemin (relatif ou absolu) et l’objet
partagé est chargé en utilisant ce chemin.
Si une dépendance d’objet partagé ne contient pas de barre oblique, alors elle est recherchée dans
l'ordre suivant :
(1) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present
and DT_RUNPATH attribute does not exist.
(2) En utilisant la variable d'environnement LD_LIBRARY_PATH, sauf si l’exécutable est utilisé dans le
mode d’exécution sécurisée (consulter ci-dessous), auquel cas elle est ignorée.
(3) En utilisant les répertoires indiqués dans l’attribut de la section dynamique DT_RUNPATH du binaire
s’il est présent. De tels répertoires sont recherchés uniquement pour trouver ces objets requis par
les entrées DT_NEEDED (dépendances directes) et ne s’appliquent pas aux enfants des objets qui
doivent eux-mêmes avoir leurs propres entrées DT_RUNPATH. Cela est différent de DT_RPATH, qui est
appliqué aux recherches pour tous les enfants dans l’arbre de dépendances.
(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-clés de chaîne dynamiques
Dans plusieurs emplacements, l’éditeur de liens dynamiques développe les mots-clés de chaîne dynamiques
- dans les variables d’environnement LD_LIBRARY_PATH, LD_PRELOAD et LD_AUDIT ;
- dans les valeurs des mots-clés 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-clés substitués sont comme suit :
$ORIGIN (ou de manière équivalente ${ORIGIN})
Cela développe le répertoire contenant le programme ou l’objet partagé. Ainsi, une application
située dans un_répertoire/app peut être compilée avec
gcc -Wl,-rpath,'$ORIGIN/../lib'
de sorte qu'elle trouvera un objet partagé associé dans un_répertoire/lib où que soit situé
un_répertoire dans la hiérarchie de répertoires. Cela facilite la création d'applications « prêtes
à l'emploi » qui n'ont pas besoin d'être installées dans un répertoire particulier mais peuvent au
contraire être installées dans n'importe quel répertoire et toujours trouver leurs propres objets
partagés.
$LIB (ou de manière équivalente ${LIB})
Cela se développe en lib ou lib64 en fonction de l'architecture (par exemple lib64 pour x86-64 ou
lib pour x86-32).
$PLATFORM (ou de manière équivalente ${PLATFORM})
Cela se développe en une chaîne correspondant au type de processeur du système hôte (par exemple
« x86_64 »). Pour certaines architectures, le noyau Linux ne fournit pas de chaîne de plateforme à
l'éditeur de liens dynamiques. La valeur de cette chaîne est issue de la valeur AT_PLATFORM du
vecteur auxiliaire (consulter getauxval(3)).
Remarquez que les mots-clés de chaîne dynamiques doivent être mis entre parenthèses correctement
lorsqu’ils sont définis à partir de l’interpréteur de commandes pour prévenir de leur développement en
tant que variables de l’interpréteur 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 nommés dans liste comme vérificateurs. Les objets sont délimités 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 réglage de la variable d’environnement LD_LIBRARY_PATH (consulter
ci-dessous). Les noms ORIGIN, LIB et PLATFORM sont interprétés 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
ignorée dans le mode d’exécution sécurisée (voir ci-dessous). Les objets dans liste sont séparés
par des deux-points ou des espaces.
--list Lister les dépendances et la manière de les résoudre.
--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)
Précharger les objets indiqués dans liste. Ces objets sont délimités par des deux-points ou des
espaces. Les objets sont préchargés comme c’est expliqué dans la description de la variable
d’environnement LD_PRELOAD ci-dessous.
Au contraire avec LD_PRELOAD, l’option --preload fournit une façon de réaliser le préchargement
pour un exécutable unique sans affecter le préchargement réalisé par un processus enfant qui
exécute un nouveau programme.
--verify
Vérifier que le programme est lié dynamiquement et que l'éditeur de liens peut le traiter.
ENVIRONNEMENT
Diverses variables d’environnement influencent les opérations de l’éditeur de liens dynamiques.
Mode d’exécution sécurisée
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 exécuté dans le mode d’exécution sécurisée si l’entrée AT_SECURE dans le vecteur
auxiliaire (consulter getauxval(3)) à une valeur différente de zéro. Cette entrée peut avoir une valeur
différente de zéro pour différentes raisons, dont :
- Les ID utilisateur réels et effectifs du processus diffèrent ou les ID de groupe réels et effectifs
diffèrent. Cela se produit classiquement lors de l’exécution d’un programme set-user-ID ou
set-group-ID ;
- Un processus avec un ID utilisateur non superutilisateur a exécuté un binaire qui conférait des
capacités au processus ;
- Une valeur différente de zéro pouvait avoir été réglée par un module de sécurité 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 être utilisé afin que l'éditeur de liens dynamiques considère qu'il est
exécuté sur un système disposant d'une version différente de l'ABI du noyau. Par exemple, la
commande suivante permet de considérer la version 2.2.5 du noyau Linux lors du chargement des
objets partagés utilisés par monprogamme:
$ LD_ASSUME_KERNEL=2.2.5 ./monprogamme
Lorsque plusieurs versions d’un même objet partagé (dans des répertoires différents du chemin de
recherche) spécifient des versions minimales d'ABI du noyau différentes, LD_ASSUME_KERNEL permet
de sélectionner la version de l’objet à utiliser (ce qui dépend de l'ordre de recherche des
répertoires).
Historiquement, LD_ASSUME_KERNEL était surtout utilisée pour sélectionner l'ancienne mise en œuvre
des threads POSIX par LinuxThreads sur les systèmes fournissant LinuxThreads et NPTL (ce dernier
étant généralement activé par défaut) ; consulter pthreads(7).
LD_BIND_NOW (depuis la glibc 2.1.1)
Si la chaîne est non vide, l'éditeur de liens résoudra tous les symboles au démarrage du programme
plutôt que repousser la résolution des noms de fonctions au moment où elles sont référencées en
premier. Cela est utile dans un débogueur.
LD_LIBRARY_PATH
Une liste de répertoires dans lesquels chercher les bibliothèques ELF au moment de l’exécution.
Les éléments de la liste sont séparés par des deux-points ou des points-virgules et il n’existe
aussi aucune protection des séparateurs. Un nom de répertoire de longueur nulle indique le
répertoire de travail en cours.
Cette variable est ignorée dans le mode d’exécution sécurisée.
À l’intérieur des noms de chemin indiqués dans LD_LIBRARY_PATH, l’éditeur de liens dynamiques
développe les mots-clés $ORIGIN, $LIB et $PLATFORM (ou les versions utilisant des accolades autour
des noms) comme cela est décrit ci-dessus dans Mots-clés de chaine dynamiques. Par conséquent, par
exemple, ce qui suit provoquera la recherche d’une bibliothèque dans les sous-répertoires lib ou
lib64 en dessous du répertoire contenant le programme à exécuter :
$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog
Remarquez l’utilisation de guillemets simples empêchant le développement de $ORIGIN et $LIB en
tant que variables d’interpréteur.
LD_PRELOAD
Une liste complémentaire, spécifiée par l’utilisateur, d’objets partagés ELF à charger avant tous
les autres objets. Cela permet de surcharger sélectivement les fonctions dans les autres objets
partagés.
Les éléments de la liste peuvent être séparés par des deux-points ou des espaces et il n’existe
aussi aucune protection des séparateurs. Les objets sont recherchés en utilisant les règles
précisées dans DESCRIPTION et sont ajoutés dans le mappage de liens dans l’ordre de droite à
gauche indiqué dans la liste.
Dans le mode d’exécution sécurisée, le préchargement de noms de chemin contenant des barres
obliques est ignoré. Par ailleurs, les objets partagés sont préchargés seulement à partir des
répertoires de recherche standard et seulement si le bit de mode set-user-ID est activé (ce qui
n’est pas habituel).
À l’intérieur des noms indiqués dans LD_PRELOAD, l’éditeur de liens dynamiques développe les
mots-clés $ORIGIN, $LIB et $PLATFORM (ou les versions utilisant des accolades autour des noms)
comme cela est décrit ci-dessus dans Mots-clés de chaine dynamiques. (Voir aussi le point sur la
mise entre parenthèses dans la description de LD_LIBRARY_PATH.)
Il existe diverses méthodes pour préciser les bibliothèques à précharger, et celles-ci sont gérées
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’éditeur de liens
dynamiques.
(3) Le fichier /etc/ld.so.preload (décrit ci-dessous).
LD_TRACE_LOADED_OBJECTS
Si la chaîne est non vide, le programme liste ses dépendances dynamiques comme s'il était lancé
par ldd(1), au lieu du lancement normal.
Il existe de nombreuses autres variables plus ou moins obscures, certaines obsolètes ou réservées pour un
usage interne.
LD_AUDIT (depuis la glibc 2.4)
Une liste d'objets partagés ELF spécifiés par l'utilisateur à charger avant tous les autres à
l'intérieur d'un espace distinct de nommage de l'éditeur de liens (c'est-à-dire qu'il n'y aura pas
d'interférence avec les liaisons sur les symboles normaux qui auront lieu pendant le processus).
Ces objets peuvent être utilisés pour contrôler les opérations effectuées par l'éditeur de liens
dynamiques. Les éléments de la liste sont séparés par des deux-points et il n’existe aucune
protection des séparateurs.
LD_AUDIT est ignorée dans le mode d’exécution sécurisée.
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.
À l’intérieur des noms indiqués dans LD_AUDIT, l’éditeur de liens dynamiques développe les
mots-clés $ORIGIN, $LIB et $PLATFORM (ou les versions utilisant des accolades autour des noms)
comme cela est décrit ci-dessus dans Mots-clés de chaine dynamiques. (Voir aussi le point sur la
mise entre parenthèses dans la description de LD_LIBRARY_PATH.)
Depuis la glibc 2.13, dans le mode d’exécution sécurisée, les noms dans la liste de contrôle
contenant des barres obliques sont ignorés et seulement les objets partagés des répertoires de
recherche standard ayant le bit de mode set-user-ID activé sont chargés.
LD_BIND_NOT (depuis la glibc 2.1.95)
Si cette variable d’environnement est réglée à une valeur non vide, ne pas mettre à jour les
tables GOT (global offset table) et PLT (procedure linkage table) après la résolution d’un symbole
de fonction. En combinant l’utilisation de cette variable avec LD_DEBUG (avec les catégories
bindings et symbols), les liaisons de fonctions d’exécution peuvent être observées.
LD_DEBUG (depuis la glibc 2.1)
Produire une information détaillée de débogage dans l’éditeur de liens dynamiques. Le contenu de
cette variable est composée d’une ou de plusieurs des catégories suivantes, séparées 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 exécuté
et qu’un message est affiché sur les catégories pouvant être indiquées dans cette
variable d’environnement.
all Afficher toutes les informations de débogage (exceptées statistics et unused ;
consulter ci-dessous).
bindings Afficher des informations sur la définition à laquelle chaque symbole est lié.
files Afficher l’avancement pour le fichier d’entrée.
libs Afficher les chemins de recherche de bibliothèque.
reloc Afficher le traitement de relocalisation
scopes Afficher des informations de portée.
statistics Afficher des statistiques de relocalisation.
symbols Afficher les chemins de recherche pour chaque consultation de symbole.
unused Identifier les objets partagés dynamiques non utilisés.
versions Afficher les dépendances de version.
Depuis la glibc 2.3.4, LD_DEBUG est ignorée dans le mode d’exécution sécurisée à moins que le
fichier /etc/suid-debug existe (le contenu du fichier est non pertinent).
LD_DEBUG_OUTPUT (depuis la glibc 2.1)
Par défaut, la sortie de LD_DEBUG est écrite sur la sortie d’erreur standard. Si LD_DEBUG_OUTPUT
est définie, alors la sortie est écrite selon le chemin défini dans sa valeur avec le suffixe
« . » (point) suivi par l’ID du processus ajouté au chemin.
LD_DEBUG_OUTPUT est ignorée dans le mode d’exécution sécurisée.
LD_DYNAMIC_WEAK (depuis la glibc 2.1.91)
Par défaut, lors de la recherche de bibliothèques partagées pour résoudre une référence de
symbole, l’éditeur de liens dynamiques résoudra la première définition 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’était pas normalisé. (La pratique normalisée consiste à ce que
la distinction entre les symboles faibles et forts intervient seulement au moment de la liaison
statique.) Dans la glibc 2.2, l’éditeur de liens dynamiques a été modifié pour fournir le
comportement actuel (qui était le comportement fourni par la plupart des autres implémentations à
ce moment là).
Définir la variable d’environnement LD_DYNAMIC_WEAK (à n’importe quelle valeur) conduit à l’ancien
comportement de la glibc non normalisé, selon lequel un symbole faible dans une bibliothèque
partagée peut être écrasé par un symbole fort trouvé ultérieurement dans une autre bibliothèque
partagée. Remarquez que même si cette variable est définie, un symbole fort dans une bibliothèque
partagée n’écrasera pas une définition faible du même symbole dans le programme principal.)
Depuis la glibc 2.3.4, LD_DYNAMIC_WEAK est ignorée dans le mode d’exécution sécurisée.
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 où le binaire est trouvé.
Depuis la glibc 2.4, LD_ORIGIN_PATH est ignorée dans le mode d’exécution sécurisée.
LD_POINTER_GUARD (from glibc 2.4 to glibc 2.22)
Mettre à zéro pour supprimer la protection sur les pointeurs. Toute autre valeur active cette
protection, ce qui est le comportement par défaut. La protection sur les pointeurs est un
mécanisme de sécurité où certains pointeurs vers du code stocké dans la zone mémoire accessible en
écriture (comme les adresses de retour conservées par setjmp(3), ou des pointeurs de fonctions
utilisés par diverses fonctions internes de glibc) sont modifiés semi-aléatoirement pour rendre
plus difficile une utilisation malveillante par un intrus, qui utiliserait par exemple un
dépassement de tampon ou de la pile. Depuis la glibc 2.23, LD_POINTER_GUARD ne peut plus être
utilisée pour désactiver cette protection, qui est toujours activée.
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)
Répertoire où sera écrit le résultat de LD_PROFILE. Si cette variable n'est pas définie, ou si
elle est définie à une valeur vide, le défaut 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 définie (à n’importe quelle valeur), afficher le tableau
auxiliaire transmis à partir du noyau (consulter aussi getauxval(3)).
Depuis la glibc 2.3.4, LD_SHOW_AUXV est ignorée dans le mode d’exécution sécurisée.
LD_TRACE_PRELINKING (from glibc 2.4 to glibc 2.35)
Si cette variable d’environnement est définie, tracer la pré-liaison de l’objet dont le nom est
assigné à cette variable d’environnement. (Utiliser ldd(1) pour obtenir une liste des objets
pouvant être tracés.) Si le nom d’objet n’est pas reconnu, alors l’activité de pré-liaison est
tracée.
LD_USE_LOAD_BIAS (from glibc 2.3.3 to glibc 2.35)
Par défaut, c'est-à-dire si cette variable n'est pas définie, les exécutables et les objets
partagés pré-liés (prelink) respectent les adresses de base des objets partagés dont ils
dépendent, alors que les exécutables PIE (position-independent executables) non pré-liés et les
autres objets partagés ne les respectent pas. Si LD_USE_LOAD_BIAS est définie à la valeur 1, les
exécutables et les PIE vont respecter les adresses de base. Si LD_USE_LOAD_BIAS est définie à 0,
ni les exécutables, ni les PIE ne respecteront les adresses de base.
Depuis la glibc 2.3.3, cette variable est ignorée dans le mode d’exécution sécurisée.
LD_VERBOSE (depuis la glibc 2.1)
S'il s'agit d'une chaîne non vide, afficher les informations sur la version des symboles du
programme si la variable d'environnement LD_TRACE_LOADED_OBJECTS a été définie.
LD_WARN (depuis la glibc 2.1.3)
Si la chaîne est non vide, avertir si un symbole n'est pas résolu.
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 prédiction de branchement peuvent être détériorées quand la cible d’un branchement
est située à plus de 4 GB du branchement. Si cette variable d’environnement est définie (à
n’importe quelle valeur), l’éditeur de liens dynamiques essaie de mapper les pages d’exécutables
en utilisant l’indicateur MAP_32BIT de mmap(2) et de revenir à un mappage sans cet indicateur si
cet essai échoue. NB : MAP_32BIT mappera avec les 2 GB bas (pas 4 GB) de l’espace d’adressage.
Parce que MAP_32BIT réduit l’éventail d’adressage pour la distribution aléatoire de l’espace
d’adressage (ASLR), LD_PREFER_MAP_32BIT_EXEC est toujours désactivée dans le mode d’exécution
sécurisée.
FICHIERS
/lib/ld.so
Le chargeur et éditeur de liens dynamiques a.out.
/lib/ld-linux.so.{1,2}
Le chargeur et éditeur de liens dynamiques ELF.
/etc/ld.so.cache
Fichier contenant la liste compilée des répertoires dans lesquels rechercher les objets partagés
et une liste d’objets partagés candidats. Consulter ldconfig(8).
/etc/ld.so.preload
Fichier contenant une liste d’objets partagés ELF, séparés par des virgules, à charger avant le
programme. Consultez le point à propos de LD_PRELOAD ci-dessus. Si LD_PRELOAD et
/etc/ld.so.preload sont employés, la bibliothèque indiquée par LD_PRELOAD est préchargée en
premier. /etc/ld.so.preload a un effet sur tout le système, faisant que les bibliothèques
indiquées sont préchargées pour tous les programmes exécutés sur le système. (Cela est
habituellement indésirable et employé uniquement comme remède d’urgence, par exemple, comme
contournement temporaire d’un problème de mauvaise configuration de bibliothèque.)
lib*.so*
Objets partagés.
NOTES
Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37)
Certains objets partagés sont compilés en utilisant des instructions spécifiques au matériel qui
n'existent pas sur tous les processeurs. Ces objets devraient être installés dans des répertoires dont
les noms définissent les capacités matérielles nécessaires, comme /usr/lib/sse2/. L'éditeur de liens
dynamiques compare ces répertoires au matériel de la machine et sélectionne la version la mieux adaptée
pour un objet partagé donné. Les répertoires de capacité matérielle peuvent être imbriqués pour combiner
les caractéristiques du microprocesseur. La liste des noms de capacité matérielle pris en charge dépend
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 française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud
<tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
<fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau
<jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François
<nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard
<simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot
<david@tilapin.org> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
Pages du manuel de Linux 6.9.1 8 mai 2024 ld.so(8)