ld.so(8) System Manager's Manual ld.so(8)
NOM
ld.so, ld-linux.so - Chargeur et éditeur de liens dynamiques
SYNOPSIS
L'éditeur de liens dynamiques peut être lancé indirectement en démar-
rant 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 com-
mande 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), ld-
config(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 re-
cherche 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épen-
dance 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) En utilisant les répertoires indiqués dans l'attribut de la sec-
tion 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.
(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 sec-
tion dynamique DT_RUNPATH du binaire s’il est présent. De tels ré-
pertoires sont recherchés uniquement pour trouver ces objets re-
quis par les entrées DT_NEEDED (dépendances directes) et ne s’ap-
pliquent 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) 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 ob-
jets 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.
(5) Dans le chemin par défaut /lib, puis /usr/lib (Sur certaines ar-
chitectures 64 bits, les chemins par défaut pour les objets parta-
gé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
• 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 proces-
seur du système hôte (par exemple « x86_64 »). Pour certaines
architectures, le noyau Linux ne fournit pas de chaîne de plate-
forme à 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’inter-
pré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.
--inhibit-cache
Ne pas utiliser /etc/ld.so.cache.
--library-path chemin
Utiliser chemin au lieu du réglage de la variable d’environne-
ment LD_LIBRARY_PATH (consulter ci-dessous). Les noms ORIGIN,
LIB et PLATFORM sont interprétés comme pour la variable d’envi-
ronnement LD_LIBRARY_PATH.
--inhibit-rpath liste
Ignorer les informations de RPATH et RUNPATH dans les noms d’ob-
jet dans liste. Cette option est ignorée dans le mode d’exécu-
tion 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-tunables (since glibc 2.33)
Print the names and values of all tunables, along with the mini-
mum and maximum allowed values.
--preload liste (depuis la glibc 2.30)
Précharger les objets indiqués dans liste. Ces objets sont déli-
mité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’édi-
teur de liens dynamiques.
Mode d’exécution sécurisée
Pour des raisons de sécurité, si l’éditeur de liens dynamiques déter-
mine qu’un binaire devrait être exécuté dans un mode d’exécution sécu-
risé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, LOCALDO-
MAIN, 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 va-
leur 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 classi-
quement 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)
Each shared object can inform the dynamic linker of the minimum
kernel ABI version that it requires. (This requirement is enco-
ded 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 com-
mande suivante permet de considérer la version 2.2.5 du noyau
Linux lors du chargement des objets partagés utilisés par mon-
progamme:
$ 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 ver-
sions 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 Linux-
Threads 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éso-
lution 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 biblio-
thè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 au-
tour des noms) comme cela est décrit ci-dessus dans Mots-clés de
chaine dynamiques. Par conséquent, par exemple, ce qui suit pro-
voquera la recherche d’une bibliothèque dans les sous-réper-
toires lib ou lib64 en dessous du répertoire contenant le pro-
gramme à exécuter :
$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog
Remarquez l’utilisation de guillemets simples empêchant le déve-
loppement 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 protec-
tion 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 $PLAT-
FORM (ou les versions utilisant des accolades autour des noms)
comme cela est décrit ci-dessus dans Mots-clés de chaine dyna-
miques. (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’invoca-
tion 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 lance-
ment normal.
Il existe de nombreuses autres variables plus ou moins obscures, cer-
taines 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épara-
teurs.
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 au-
dit 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 $PLAT-
FORM (ou les versions utilisant des accolades autour des noms)
comme cela est décrit ci-dessus dans Mots-clés de chaine dyna-
miques. (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 sym-
bole 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 indi-
quées dans cette variable d’environnement.
all Afficher toutes les informations de débogage (excep-
tées statistics et unused ; consulter ci-dessous).
bindings Afficher des informations sur la définition à la-
quelle 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 utili-
sé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’er-
reur 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 be-
havior: if the linker found a symbol that was weak, it would re-
member 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 dyna-
miques a été modifié pour fournir le comportement actuel (qui
était le comportement fourni par la plupart des autres implémen-
tations à 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érieure-
ment dans une autre bibliothèque partagée. Remarquez que même si
cette variable est définie, un symbole fort dans une biblio-
thè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 (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 com-
portement 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 fonc-
tions utilisés par diverses fonctions internes de glibc) sont
modifiés semi-aléatoirement pour rendre plus difficile une uti-
lisation 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.pro-
file ».
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 va-
riable 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écuri-
sé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 ob-
jets 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) res-
pectent 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'environne-
ment 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 bran-
chement est située à plus de 4 GB du branchement. Si cette va-
riable 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 dis-
tribution aléatoire de l’espace d’adressage (ASLR), LD_PRE-
FER_MAP_32BIT_EXEC est toujours désactivée dans le mode d’exécu-
tion 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 les-
quels rechercher les objets partagés et une liste d’objets par-
tagé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.pre-
load 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échar-
gé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 pro-
blè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 micropro-
cesseur. 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, efp-
double, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, po-
wer5, 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), ca-
pabilities(7), rtld-audit(7), ldconfig(8), sln(8)
TRADUCTION
La traduction française de cette page de manuel a été créée par Chris-
tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <ste-
phan.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.cou-
lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centra-
liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <si-
mon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@de-
bian.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⟩.
Pages du manuel de Linux 6.03 5 février 2023 ld.so(8)
Generated by dwww version 1.15 on Sat Jun 29 01:52:00 CEST 2024.