Provided by: manpages-fr_4.13-4_all bug

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 ⟨⟩.