Provided by: manpages-fr_4.19.0-7_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⟩.