noble (8) ld-linux.so.8.gz

Provided by: manpages-fr_4.21.0-2_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 :

       (1)  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.

       (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 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.

       (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  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.

       (5)  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

       -  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 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

       --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’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.

       --list-tunables (since glibc 2.33)
              Print the names and values of all tunables, along with the minimum and maximum allowed values.

       --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)
              Each  shared  object  can  inform  the  dynamic  linker  of the minimum kernel ABI version that it
              requires. (This requirement is encoded 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
              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.

              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  audit  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 $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.

              Old glibc versions (before glibc 2.2), provided a different behavior: if the linker found a symbol
              that was weak, it would remember 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  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 (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  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)

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