Provided by: manpages-fr_3.65d1p1-1_all bug

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 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 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.65 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> ».