Provided by: manpages-fr_4.13-4_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 :
o En utilisant les répertoires indiqués dans l'attribut de la section dynamique DT_RPATH
du fichier binaire s'il est présent et si l'attribut DT_RUNPATH n'existe pas.
L'utilisation de DT_RPATH est déconseillée.
o 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.
o 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.
o Depuis le fichier cache /etc/ld.so.cache, qui contient une liste compilée des objets
partagés candidats précédemment trouvés dans le chemin élargi de bibliothèque. Si
toutefois le fichier binaire a été lié avec l'option -z nodeflib de l'éditeur de liens,
les objets partagés dans les chemins par défaut sont ignorés. Les objets partagés
installés dans les répertoires de capacité matérielle (consulter ci-dessous) sont
préférés aux autres objets partagés.
o Dans le chemin par défaut /lib, puis /usr/lib (Sur certaines architectures 64 bits, les
chemins par défaut pour les objets partagés 64 bits sont /lib64 et puis /usr/lib64.) Si
le binaire a été lié avec l'option -z nodeflib de l'éditeur de liens, cette étape est
sautée.
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
o dans les variables d’environnement LD_LIBRARY_PATH, LD_PRELOAD et LD_AUDIT ;
o 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 ;
o dans les arguments des options de ld.so dans la ligne de commande --audit,
--library-path et --preload (consulter ci-dessous) ;
o 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
--audit liste
Utiliser les objets nommés dans liste comme vérificateurs. Les objets sont
délimités par des deux-points.
--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.
--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
Pour des raisons de sécurité, si l’éditeur de liens dynamiques détermine qu’un binaire
devrait être exécuté dans un mode d’exécution sécurisée, les effets de quelques variables
d’environnement sont annulés ou modifiés, et en outre ces variables d’environnement sont
enlevées de l’environnement de telle façon que le programme ne puisse même pas voir les
définitions. Certaines de ces variables d’environnement affectent les opérations de
l’éditeur de liens dynamiques lui-même et sont décrites ci-dessous. Les autres variables
d’environnement traitées de cette manière incluent GCONV_PATH, GETCONF_DIR, HOSTALIASES,
LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS,
TMPDIR et 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 (depuis la glibc 2.2.3)
Tout objet partagé peut informer l'éditeur de liens dynamiques de la version
minimale requise de l'ABI du noyau. (Cette exigence est enregistrée dans une
section de note ELF, qui peut être lue avec readelf -n sous le nom NT_GNU_ABI_TAG.)
Lors de l'exécution, l'éditeur de liens dynamiques détermine la version d'ABI du
noyau exécutée et rejettera le chargement de tout objet partagé qui spécifie une
version minimale d'ABI supérieure.
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.
L'éditeur de liens dynamiques notifiera les objets partagés de contrôle aux
endroits précis de contrôle (par exemple au chargement d'un nouvel objet partagé, à
la résolution d'un symbole, à l'appel d'un symbole depuis un autre objet partagé
— en appelant la fonction adéquate dans l’objet partagé de contrôle. Pour des
informations plus détaillées, consultez rtld-audit(7). L'interface de contrôle est
largement compatible avec celle disponible sur Solaris, décrite dans le Linker and
Libraries Guide, au chapitre 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.
Les anciennes versions de la glibc (avant la version 2.2) procuraient un
comportement différent. Si l’éditeur de liens trouvait un symbole faible, il se
souvenait de ce symbole et continuait à chercher parmi les bibliothèques partagées
restantes. S’il trouvait une définition forte du même symbole, il utilisait plutôt
cette définition. (Si aucune n’était trouvée, alors l’éditeur de liens dynamiques
utilisait le symbole faible précédemment trouvé.)
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 (depuis la glibc 2.1)
Masque des capacités matérielles.
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 (dans la glibc depuis 2.4 jusqu’à 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)
Le nom d'un (seul) objet partagé à profiler, spécifié par un chemin ou par un
soname. Le résultat du profilage est écrit dans un fichier dont le nom est
« $LD_PROFILE_OUTPUT/$LD_PROFILE.profile ».
Depuis la glibc 2.2.5, LD_PROFILE est ignorée dans le mode d’exécution sécurisée.
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 est ignorée dans le mode d’exécution sécurisée. À la place
/var/profile est toujours utilisé. (Ce détail est pertinent seulement depuis la
glibc 2.2.5, puisque dans les versions postérieures , LD_PROFILE est aussi ignorée
dans le mode d’exécution sécurisée.)
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 (depuis la glibc 2.4)
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 (depuis la glibc 2.3.3)
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
Capacités matérielles
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
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)
COLOPHON
Cette page fait partie de la publication 5.10 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies et la dernière version de cette
page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.
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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨⟩.