Provided by: manpages-fr_3.57d1p1-1_all 
NOM
ld.so, ld-linux.so* - Chargeur et éditeur de liens dynamique
SYNOPSIS
L'éditeur de liens dynamique peut être lancé indirectement en démarrant un programme lié
dynamiquement ou une bibliothèque (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 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 dynamique (au démarrage) sauf si
l'option -static a été indiquée sur la ligne de commande de ld durant la compilation.
Le programme ld.so traite les binaires a.out, un format utilisé il y a bien longtemps ;
ld-linux.so* traitent les fichiers ELF (/lib/ld-linux.so.1 pour libc5, /lib/ld-linux.so.2
pour glibc2), que tout le monde utilise depuis des années. Autrement, les deux programmes
ont le même comportement et utilisent les fichiers et programmes ldd(1), ldconfig(8) et
/etc/ld.so.conf.
Lors de la résolution des dépendances de bibliothèques, l'éditeur de liens dynamique
inspecte d'abord chaque chaîne de dépendance à la recherche d'une barre oblique (cela peut
arriver si un chemin de bibliothèque contenant des barres obliques a été indiqué au moment
du lien). 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 la bibliothèque est chargée en utilisant ce chemin.
Si une dépendance de bibliothèque de contient pas de barre oblique, alors elle est
recherchée dans l'ordre suivant :
o (ELF seulement) En utilisant les répertoires indiqués dans l'attribut de section
dynamique DT_RPATH du fichier binaire s'il est présent, et l'attribut DT_RUNPATH sinon.
L'utilisation de DT_RPATH est déconseillée.
o En utilisant la variable d'environnement LD_LIBRARY_PATH, sauf si les bits d'emprunt
des identifiants d'utilisateur (setuid) ou de groupe (setgid) de l'exécutable sont non
nuls (par souci de simplification, on parlera ci-dessous d'exécutable setuid ou
setgid), auquel cas elle est ignorée.
o (ELF seulement) En utilisant les répertoires indiqués dans l'attribut de section
dynamique DT_RUNPATH du fichier binaire s'il est présent.
o Depuis le fichier cache /etc/ld.so.cache, qui contient une liste compilée de
bibliothèques précédemment trouvées dans des chemins par défaut. Si toutefois le
fichier binaire a été lié avec l'option -z nodeflib de l'éditeur de liens, les chemins
par défaut sont ignorés. Les bibliothèques installées dans les répertoires de capacité
matérielle (voir ci-dessous) sont préférées aux autres bibliothèques.
o Dans le répertoire par défaut /lib, puis /usr/lib. Si le binaire a été lié avec
l'option -z nodeflib de l'éditeur de lien, cette étape est sautée.
Développement des mots-clés rpath
ld.so comprend certaines chaînes dans une spécification rpath (DT_RPATH ou DT_RUNPATH) ;
ces chaines sont substituées ainsi :
$ORIGIN (ou de manière équivalente ${ORIGIN})
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 une bibliothèque partagée associée dans un_répertoire/lib
où que soit situé un_répertoire dans la hiérarchie du répertoire. 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 bibliothèques
partagées.
$LIB (ou de manière équivalente ${LIB})
Est développé 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})
Est développé 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 caractère à l'éditeur de liens dynamique. La valeur de cette chaîne
est issue de la valeur AT_PLATFORM du vecteur auxiliaire (voir getauxval(3)).
OPTIONS
--list Liste les dépendances et leurs résolutions.
--verify
Vérifie que le programme est lié dynamiquement et que l'éditeur de liens peut le
traiter.
--library-path CHEMIN
Utiliser CHEMIN à la place de la variable d'environnement LD_LIBRARY_PATH (voir
plus bas).
--inhibit-rpath LISTE
Ignorer les informations RPATH et RUNPATH dans les objets de la LISTE. Cette option
est ignorée si ld.so est setuid ou setgid.
--audit LISTE
Utilisez les objets nommés dans LISTE comme auditeurs.
CAPACITÉS MATÉRIELLES
Certaines bibliothèques sont compilées en utilisant des instructions spécifiques au
matériel qui n'existent pas sur tous les processeurs. Ces bibliothèques devraient être
installées dans des répertoires dont les noms définissent les capacités matérielles
nécessaires, comme /usr/lib/sse2/. L'éditeur de liens dynamique compare ces répertoires au
matériel de la machine et sélectionne la version la mieux adaptée pour une bibliothèque
donnée. 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
ENVIRONNEMENT
Parmi les variables d'environnement importantes, on trouve :
LD_ASSUME_KERNEL
(glibc depuis 2.2.3) Toute bibliothèque partagée peut informer l'éditeur de liens
dynamique de la version minimale requise de l'ABI 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 dynamique détermine la
version d'ABI du noyau exécuté et rejettera le chargement de toute bibliothèque
partagée qui spécifie une version minimale d'ABI supérieure.
LD_ASSUME_KERNEL peut être utilisé afin que l'éditeur de liens dynamique considère
qu'il est exécuté sur un système disposant d'une version différente de l'ABI noyau.
Par exemple, la commande suivante permet de considérer la version 2.2.5 du noyau
Linux lors du chargement des bibliothèques partagées utilisées par monprogamme:
$ LD_ASSUME_KERNEL=2.2.5 ./monprogamme
Lorsque plusieurs versions d'une même bibliothèque partagée (dans des répertoires
différents du chemin de recherche) spécifient des versions minimales d'ABI noyau
différents, LD_ASSUME_KERNEL permet de sélectionner la version de la bibliothèque à
utiliser (ce qui dépend de l'ordre de recherche des répertoires). Historiquement,
LD_ASSUME_KERNEL était surtout utilisé 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); voir pthreads(7).
LD_BIND_NOT
(glibc depuis 2.2) Ne pas mettre à jour les tables GOT (global offset table) et PLT
(procedure linkage table) lors de la résolution d'un symbole.
LD_BIND_NOW
(libc5 ; glibc depuis 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. Ceci est utile
dans un débogueur.
LD_LIBRARY_PATH
Comme la variable d'environnement PATH, cette variable contient une liste de
répertoires séparés par des deux-points. Les bibliothèques au format ELF sont
recherchées à l'exécution dans ces répertoires. Ignorée dans les programmes setuid
ou setgid.
LD_PRELOAD
Une liste de bibliothèques ELF spécifiques à l'utilisateur, à charger avant les
autres bibliothèques. Les éléments de la liste peuvent être séparés par des espaces
ou des deux points. Cela permet de surcharger sélectivement les fonctions des
autres bibliothèques partagées. Les bibliothèques sont recherchées pour une
utilisation des règles données en DESCRIPTION. Pour les binaires ELF setuid ou
setgid, les chemins de préchargement contenant des barres obliques sont ignorés, et
les bibliothèques des répertoires standard ne sont chargées que si le bit de droit
setuid est activé sur le fichier de bibliothèque.
LD_TRACE_LOADED_OBJECTS
(ELF seulement) 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_AOUT_LIBRARY_PATH
(libc5) Version de LD_LIBRARY_PATH pour les binaires a.out seulement. Les anciennes
versions de ld-linux.so.1 supportent LD_ELF_LIBRARY_PATH.
LD_AOUT_PRELOAD
(libc5) Version de LD_PRELOAD pour les binaires a.out seulement. Les anciennes
versions de ld-linux.so.1 supportent LD_ELF_PRELOAD.
LD_AUDIT
(glibc depuis 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 de nommage de l'éditeur de
liens séparé (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 bibliothèques
peuvent être utilisées pour auditer les opérations effectuées par l'éditeur de
liens dynamique. LD_AUDIT est ignorée pour les exécutables setuid ou setgid.
L'éditeur de liens dynamique notifiera les bibliothèques d'audit à des endroits
précis d'audit (appelés auditing checkpoints) — par exemple au chargement d'une
nouvelle bibliothèque, à la résolution d'un symbole, à l'appel d'un symbole depuis
un autre objet partagé — en appelant la fonction adéquate de la bibliothèque
d'audit. Pour des informations plus détaillées, consultez rtld-audit(7).
L'interface d'audit est largement compatible avec celle disponible sur Solaris,
décrite dans le Linker and Libraries Guide, au chapitre Runtime Linker Auditing
Interface.
LD_BIND_NOT
(glibc depuis 2.1.95) Ne pas mettre à jour les tables GOT (global offset table) et
PLT (procedure linkage table) après résolution d'un symbole.
LD_DEBUG
(glibc depuis 2.1) Afficher de nombreuses informations de débogage de l'éditeur
dynamique. Si elle contient all, afficher tous les messages d'information, si elle
contient help, afficher un message d'aide à propos des catégories de messages pour
cette variable d'environnement. Depuis glibc 2.3.4, LD_DEBUG n'est pas pris en
compte pour les exécutables setuid ou setgid.
LD_DEBUG_OUTPUT
(glibc depuis 2.1) Fichier où la sortie de LD_DEBUG devrait être envoyée. Par
défaut, c'est la sortie d'erreur standard. LD_DEBUG_OUTPUT est ignorée pour les
exécutables setuid ou setgid.
LD_DYNAMIC_WEAK
(glibc depuis 2.1.91) Autorise la surcharge des symboles faibles (retour à l'ancien
comportement). Pour des raisons de sécurité, depuis glibc 2.3.4, LD_DYNAMIC_WEAK
est ignorée pour les exécutables setuid ou setgid.
LD_HWCAP_MASK
(glibc depuis 2.1) Masque des capacités matérielles.
LD_KEEPDIR
(a.out seulement)(libc5) Ne pas ignorer le répertoire dans les noms de
bibliothèques a.out. Cette option est très déconseillée.
LD_NOWARN
(a.out seulement)(libc5) Supprimer les avertissements à propos des bibliothèques
a.out incompatibles avec les versions antérieures.
LD_ORIGIN_PATH
(glibc depuis 2.1) Chemin où se trouve l'exécutable (pour des programmes non
setuid). Pour des raisons de sécurité, depuis glibc 2.4, LD_ORIGIN_PATH est ignorée
pour les exécutables setuid ou setgid.
LD_POINTER_GUARD
(glibc depuis 2.4) Mettre à 0 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.
LD_PROFILE
(glibc depuis 2.1) Objet partagé à profiler, spécifié par un chemin ou par un nom
d'objet partagé (soname). Le résultat du profilage est écrit dans un fichier dont
le nom est « $LD_PROFILE_OUTPUT/$LD_PROFILE.profile ».
LD_PROFILE_OUTPUT
(glibc depuis 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 pour les exécutables setuid ou setgid,
auquel cas le répertoire utilisé sera toujours /var/profile.
LD_SHOW_AUXV
(glibc depuis 2.1) Affiche les tableaux auxiliaires passés depuis le kernel. Pour
des raisons de sécurité, depuis glibc 2.3.5, LD_SHOW_AUXV est ignorée pour les
exécutables setuid ou setgid.
LD_USE_LOAD_BIAS
Par défaut, c'est-à-dire si cette variable n'est pas définie, les exécutables et
les objets partagés préchargés (prelink) respectent l'adresse de base des
bibliothèques dont ils dépendent, alors que les exécutables PIE
(position-independent executables) non préchargés et les autres objets partagés ne
les respectent pas. Si LD_USE_LOAD_BIAS est définie à une valeur non nulle, 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.
Cette variable est ignorée pour les exécutables setuid ou setgid.
LD_VERBOSE
(glibc depuis 2.1) S'il s'agit d'une chaîne non vide, afficher les informations sur
la version des objets sur le programme si la variable d'environnement
LD_TRACE_LOADED_OBJECTS a été définie.
LD_WARN
(ELF seulement)(glibc depuis 2.1.3) Si la chaîne est non vide, avertir si un
symbole n'est pas résolu.
LDD_ARGV0
(libc5) argv[0] à utiliser par ldd(1) si aucun n'est présent.
FICHIERS
/lib/ld.so
Le chargeur et éditeur de liens dynamique a.out.
/lib/ld-linux.so.{1,2}
Le chargeur et éditeur de liens dynamique ELF.
/etc/ld.so.cache
Fichier contenant la liste compilée des répertoires où se trouvent des
bibliothèques, ainsi qu'une liste ordonnée de bibliothèques candidates.
/etc/ld.so.preload
Fichier contenant une liste de bibliothèques ELF, séparées par des espaces, à
charger avant de démarrer le programme.
lib*.so*
Bibliothèques partagées.
NOTES
Les fonctionnalités ld.so sont disponibles pour les exécutables compilés à partir de la
libc version 4.4.3 et ultérieures. Les fonctionnalités ELF sont disponibles depuis 1.1.52
et la libc5.
VOIR AUSSI
ldd(1), getauxval(3), rtld-audit(7), ldconfig(8), sln(8)
COLOPHON
Cette page fait partie de la publication 3.57 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies peuvent être trouvées à
l'adresse http://www.kernel.org/doc/man-pages/.
TRADUCTION
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet
perkamon <http://perkamon.alioth.debian.org/>.
Christophe Blaess <http://www.blaess.fr/christophe/> (2003-2008).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la
commande « man -L C <section> <page_de_man> ».