ld.so(8) System Manager's Manual ld.so(8) NOM ld.so, ld-linux.so - Chargeur et editeur de liens dynamiques SYNOPSIS L'editeur de liens dynamiques peut etre lance indirectement en demarrant un programme lie dynamiquement ou un objet partage (dans ce cas, aucune option en ligne de commande ne peut etre transmise, et avec ELF, l'editeur indique dans la section .interp du programme est execute), ou directement en lancant : /lib/ld-linux.so.* [OPTIONS] [PROGRAMME [ARGUMENTS]] DESCRIPTION Les programmes ld.so et ld-linux.so* trouvent et chargent les objets partages (bibliotheques partagees) necessaires pour un programme, preparent son demarrage et le lancent. Les binaires Linux necessitent une edition de liens dynamiques (au demarrage) sauf si l'option -static a ete indiquee sur la ligne de commande de ld(1) durant la compilation. Le programme ld.so traite les binaires a.out, un format utilise 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 meme comportement et utilisent les memes fichiers d'aide et memes programmes (ldd(1), ldconfig(8) et /etc/ld.so.conf). Lors de la resolution des dependances d'objets partages, l'editeur de liens dynamiques inspecte d'abord chaque chaine de dependance a la recherche d'une barre oblique (cela peut arriver si un chemin d'objet partage contenant des barres obliques a ete indique au moment de la liaison). Si une barre oblique est trouvee, alors la chaine de dependance est interpretee comme un chemin (relatif ou absolu) et l'objet partage est charge en utilisant ce chemin. Si une dependance d'objet partage ne contient pas de barre oblique, alors elle est recherchee dans l'ordre suivant : (1) En utilisant les repertoires indiques dans l'attribut de la section dynamique DT_RPATH du fichier binaire s'il est present et si l'attribut DT_RUNPATH n'existe pas. L'utilisation de DT_RPATH est deconseillee. (2) En utilisant la variable d'environnement LD_LIBRARY_PATH, sauf si l'executable est utilise dans le mode d'execution securisee (consulter ci-dessous), auquel cas elle est ignoree. (3) En utilisant les repertoires indiques dans l'attribut de la section dynamique DT_RUNPATH du binaire s'il est present. De tels repertoires sont recherches uniquement pour trouver ces objets requis par les entrees DT_NEEDED (dependances directes) et ne s'appliquent pas aux enfants des objets qui doivent eux-memes avoir leurs propres entrees DT_RUNPATH. Cela est different de DT_RPATH, qui est applique aux recherches pour tous les enfants dans l'arbre de dependances. (4) From the cache file /etc/ld.so.cache, which contains a compiled list of candidate shared objects previously found in the augmented library path. If, however, the binary was linked with the -z nodefaultlib linker option, shared objects in the default paths are skipped. Shared objects installed in hardware capability directories (see below) are preferred to other shared objects. (5) In the default path /lib, and then /usr/lib. (On some 64-bit architectures, the default paths for 64-bit shared objects are /lib64, and then /usr/lib64.) If the binary was linked with the -z nodefaultlib linker option, this step is skipped. Mots-cles de chaine dynamiques Dans plusieurs emplacements, l'editeur de liens dynamiques developpe les mots-cles de chaine dynamiques - dans les variables d'environnement LD_LIBRARY_PATH, LD_PRELOAD et LD_AUDIT ; - dans les valeurs des mots-cles 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-cles substitues sont comme suit : $ORIGIN (ou de maniere equivalente ${ORIGIN}) Cela developpe le repertoire contenant le programme ou l'objet partage. Ainsi, une application situee dans un_repertoire/app peut etre compilee avec gcc -Wl,-rpath,'$ORIGIN/../lib' de sorte qu'elle trouvera un objet partage associe dans un_repertoire/lib ou que soit situe un_repertoire dans la hierarchie de repertoires. Cela facilite la creation d'applications << pretes a l'emploi >> qui n'ont pas besoin d'etre installees dans un repertoire particulier mais peuvent au contraire etre installees dans n'importe quel repertoire et toujours trouver leurs propres objets partages. $LIB (ou de maniere equivalente ${LIB}) Cela se developpe en lib ou lib64 en fonction de l'architecture (par exemple lib64 pour x86-64 ou lib pour x86-32). $PLATFORM (ou de maniere equivalente ${PLATFORM}) Cela se developpe en une chaine correspondant au type de processeur du systeme hote (par exemple << x86_64 >>). Pour certaines architectures, le noyau Linux ne fournit pas de chaine de plateforme a l'editeur de liens dynamiques. La valeur de cette chaine est issue de la valeur AT_PLATFORM du vecteur auxiliaire (consulter getauxval(3)). Remarquez que les mots-cles de chaine dynamiques doivent etre mis entre parentheses correctement lorsqu'ils sont definis a partir de l'interpreteur de commandes pour prevenir de leur developpement en tant que variables de l'interpreteur 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 nommes dans liste comme verificateurs. Les objets sont delimites par des deux-points. --glibc-hwcaps-mask list only search built-in subdirectories if in list. --glibc-hwcaps-prepend list Search glibc-hwcaps subdirectories in list. --inhibit-cache Ne pas utiliser /etc/ld.so.cache. --library-path chemin Utiliser chemin au lieu du reglage de la variable d'environnement LD_LIBRARY_PATH (consulter ci-dessous). Les noms ORIGIN, LIB et PLATFORM sont interpretes 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 ignoree dans le mode d'execution securisee (voir ci-dessous). Les objets dans liste sont separes par des deux-points ou des espaces. --list Lister les dependances et la maniere de les resoudre. --list-diagnostics (since glibc 2.33) Print system diagnostic information in a machine-readable format, such as some internal loader variables, the auxiliary vector (see getauxval(3)), and the environment variables. On some architectures, the command might print additional information (like the cpu features used in GNU indirect function selection on x86). --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) Precharger les objets indiques dans liste. Ces objets sont delimites par des deux-points ou des espaces. Les objets sont precharges comme c'est explique dans la description de la variable d'environnement LD_PRELOAD ci-dessous. Au contraire avec LD_PRELOAD, l'option --preload fournit une facon de realiser le prechargement pour un executable unique sans affecter le prechargement realise par un processus enfant qui execute un nouveau programme. --verify Verifier que le programme est lie dynamiquement et que l'editeur de liens peut le traiter. ENVIRONNEMENT Diverses variables d'environnement influencent les operations de l'editeur de liens dynamiques. Mode d'execution securisee For security reasons, if the dynamic linker determines that a binary should be run in secure-execution mode, the effects of some environment variables are voided or modified, and furthermore those environment variables are stripped from the environment, so that the program does not even see the definitions. Some of these environment variables affect the operation of the dynamic linker itself, and are described below. Other environment variables treated in this way include: GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN, LD_AUDIT, LD_DEBUG, LD_DEBUG_OUTPUT, LD_DYNAMIC_WEAK, LD_HWCAP_MASK, LD_LIBRARY_PATH, LD_ORIGIN_PATH, LD_PRELOAD, LD_PROFILE, LD_SHOW_AUXV, LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS, TMPDIR, and TZDIR. Un binaire est execute dans le mode d'execution securisee si l'entree AT_SECURE dans le vecteur auxiliaire (consulter getauxval(3)) a une valeur differente de zero. Cette entree peut avoir une valeur differente de zero pour differentes raisons, dont : - Les ID utilisateur reels et effectifs du processus different ou les ID de groupe reels et effectifs different. Cela se produit classiquement lors de l'execution d'un programme set-user-ID ou set-group-ID ; - Un processus avec un ID utilisateur non superutilisateur a execute un binaire qui conferait des capacites au processus ; - Une valeur differente de zero pouvait avoir ete reglee par un module de securite de Linux. Variables d'environnement Parmi les variables d'environnement importantes, on trouve : LD_ASSUME_KERNEL (from glibc 2.2.3 to glibc 2.36) 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 etre utilise afin que l'editeur de liens dynamiques considere qu'il est execute sur un systeme disposant d'une version differente de l'ABI du noyau. Par exemple, la commande suivante permet de considerer la version 2.2.5 du noyau Linux lors du chargement des objets partages utilises par monprogamme: $ LD_ASSUME_KERNEL=2.2.5 ./monprogamme Lorsque plusieurs versions d'un meme objet partage (dans des repertoires differents du chemin de recherche) specifient des versions minimales d'ABI du noyau differentes, LD_ASSUME_KERNEL permet de selectionner la version de l'objet a utiliser (ce qui depend de l'ordre de recherche des repertoires). Historiquement, LD_ASSUME_KERNEL etait surtout utilisee pour selectionner l'ancienne mise en oeuvre des threads POSIX par LinuxThreads sur les systemes fournissant LinuxThreads et NPTL (ce dernier etant generalement active par defaut) ; consulter pthreads(7). LD_BIND_NOW (depuis la glibc 2.1.1) Si la chaine est non vide, l'editeur de liens resoudra tous les symboles au demarrage du programme plutot que repousser la resolution des noms de fonctions au moment ou elles sont referencees en premier. Cela est utile dans un debogueur. LD_LIBRARY_PATH Une liste de repertoires dans lesquels chercher les bibliotheques ELF au moment de l'execution. Les elements de la liste sont separes par des deux-points ou des points-virgules et il n'existe aussi aucune protection des separateurs. Un nom de repertoire de longueur nulle indique le repertoire de travail en cours. Cette variable est ignoree dans le mode d'execution securisee. A l'interieur des noms de chemin indiques dans LD_LIBRARY_PATH, l'editeur de liens dynamiques developpe les mots-cles $ORIGIN, $LIB et $PLATFORM (ou les versions utilisant des accolades autour des noms) comme cela est decrit ci-dessus dans Mots-cles de chaine dynamiques. Par consequent, par exemple, ce qui suit provoquera la recherche d'une bibliotheque dans les sous-repertoires lib ou lib64 en dessous du repertoire contenant le programme a executer : $ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog Remarquez l'utilisation de guillemets simples empechant le developpement de $ORIGIN et $LIB en tant que variables d'interpreteur. LD_PRELOAD Une liste complementaire, specifiee par l'utilisateur, d'objets partages ELF a charger avant tous les autres objets. Cela permet de surcharger selectivement les fonctions dans les autres objets partages. Les elements de la liste peuvent etre separes par des deux-points ou des espaces et il n'existe aussi aucune protection des separateurs. Les objets sont recherches en utilisant les regles precisees dans DESCRIPTION et sont ajoutes dans le mappage de liens dans l'ordre de droite a gauche indique dans la liste. Dans le mode d'execution securisee, le prechargement de noms de chemin contenant des barres obliques est ignore. Par ailleurs, les objets partages sont precharges seulement a partir des repertoires de recherche standard et seulement si le bit de mode set-user-ID est active (ce qui n'est pas habituel). A l'interieur des noms indiques dans LD_PRELOAD, l'editeur de liens dynamiques developpe les mots-cles $ORIGIN, $LIB et $PLATFORM (ou les versions utilisant des accolades autour des noms) comme cela est decrit ci-dessus dans Mots-cles de chaine dynamiques. (Voir aussi le point sur la mise entre parentheses dans la description de LD_LIBRARY_PATH.) Il existe diverses methodes pour preciser les bibliotheques a precharger, et celles-ci sont gerees 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'editeur de liens dynamiques. (3) Le fichier /etc/ld.so.preload (decrit ci-dessous). LD_TRACE_LOADED_OBJECTS Si la chaine est non vide, le programme liste ses dependances dynamiques comme s'il etait lance par ldd(1), au lieu du lancement normal. Il existe de nombreuses autres variables plus ou moins obscures, certaines obsoletes ou reservees pour un usage interne. LD_AUDIT (depuis la glibc 2.4) Une liste d'objets partages ELF specifies par l'utilisateur a charger avant tous les autres a l'interieur d'un espace distinct de nommage de l'editeur de liens (c'est-a-dire qu'il n'y aura pas d'interference avec les liaisons sur les symboles normaux qui auront lieu pendant le processus). Ces objets peuvent etre utilises pour controler les operations effectuees par l'editeur de liens dynamiques. Les elements de la liste sont separes par des deux-points et il n'existe aucune protection des separateurs. LD_AUDIT est ignoree dans le mode d'execution securisee. 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. A l'interieur des noms indiques dans LD_AUDIT, l'editeur de liens dynamiques developpe les mots-cles $ORIGIN, $LIB et $PLATFORM (ou les versions utilisant des accolades autour des noms) comme cela est decrit ci-dessus dans Mots-cles de chaine dynamiques. (Voir aussi le point sur la mise entre parentheses dans la description de LD_LIBRARY_PATH.) Depuis la glibc 2.13, dans le mode d'execution securisee, les noms dans la liste de controle contenant des barres obliques sont ignores et seulement les objets partages des repertoires de recherche standard ayant le bit de mode set-user-ID active sont charges. LD_BIND_NOT (depuis la glibc 2.1.95) Si cette variable d'environnement est reglee a une valeur non vide, ne pas mettre a jour les tables GOT (global offset table) et PLT (procedure linkage table) apres la resolution d'un symbole de fonction. En combinant l'utilisation de cette variable avec LD_DEBUG (avec les categories bindings et symbols), les liaisons de fonctions d'execution peuvent etre observees. LD_DEBUG (depuis la glibc 2.1) Produire une information detaillee de debogage dans l'editeur de liens dynamiques. Le contenu de cette variable est composee d'une ou de plusieurs des categories suivantes, separees 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 execute et qu'un message est affiche sur les categories pouvant etre indiquees dans cette variable d'environnement. all Afficher toutes les informations de debogage (exceptees statistics et unused ; consulter ci-dessous). bindings Afficher des informations sur la definition a laquelle chaque symbole est lie. files Afficher l'avancement pour le fichier d'entree. libs Afficher les chemins de recherche de bibliotheque. reloc Afficher le traitement de relocalisation scopes Afficher des informations de portee. statistics Afficher des statistiques de relocalisation. symbols Afficher les chemins de recherche pour chaque consultation de symbole. unused Identifier les objets partages dynamiques non utilises. versions Afficher les dependances de version. Depuis la glibc 2.3.4, LD_DEBUG est ignoree dans le mode d'execution securisee a moins que le fichier /etc/suid-debug existe (le contenu du fichier est non pertinent). LD_DEBUG_OUTPUT (depuis la glibc 2.1) Par defaut, la sortie de LD_DEBUG est ecrite sur la sortie d'erreur standard. Si LD_DEBUG_OUTPUT est definie, alors la sortie est ecrite selon le chemin defini dans sa valeur avec le suffixe << . >> (point) suivi par l'ID du processus ajoute au chemin. LD_DEBUG_OUTPUT est ignoree dans le mode d'execution securisee. LD_DYNAMIC_WEAK (depuis la glibc 2.1.91) Par defaut, lors de la recherche de bibliotheques partagees pour resoudre une reference de symbole, l'editeur de liens dynamiques resoudra la premiere definition 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'etait pas normalise. (La pratique normalisee consiste a ce que la distinction entre les symboles faibles et forts intervient seulement au moment de la liaison statique.) Dans la glibc 2.2, l'editeur de liens dynamiques a ete modifie pour fournir le comportement actuel (qui etait le comportement fourni par la plupart des autres implementations a ce moment la). Definir la variable d'environnement LD_DYNAMIC_WEAK (a n'importe quelle valeur) conduit a l'ancien comportement de la glibc non normalise, selon lequel un symbole faible dans une bibliotheque partagee peut etre ecrase par un symbole fort trouve ulterieurement dans une autre bibliotheque partagee. Remarquez que meme si cette variable est definie, un symbole fort dans une bibliotheque partagee n'ecrasera pas une definition faible du meme symbole dans le programme principal.) Depuis la glibc 2.3.4, LD_DYNAMIC_WEAK est ignoree dans le mode d'execution securisee. LD_HWCAP_MASK (from glibc 2.1 to glibc 2.38) Mask for hardware capabilities. Since glibc 2.26, the option might be ignored if glibc does not support tunables. LD_ORIGIN_PATH (depuis la glibc 2.1) Chemin ou le binaire est trouve. Depuis la glibc 2.4, LD_ORIGIN_PATH est ignoree dans le mode d'execution securisee. LD_POINTER_GUARD (from glibc 2.4 to glibc 2.22) Mettre a zero pour supprimer la protection sur les pointeurs. Toute autre valeur active cette protection, ce qui est le comportement par defaut. La protection sur les pointeurs est un mecanisme de securite ou certains pointeurs vers du code stocke dans la zone memoire accessible en ecriture (comme les adresses de retour conservees par setjmp(3), ou des pointeurs de fonctions utilises par diverses fonctions internes de glibc) sont modifies semi-aleatoirement pour rendre plus difficile une utilisation malveillante par un intrus, qui utiliserait par exemple un depassement de tampon ou de la pile. Depuis la glibc 2.23, LD_POINTER_GUARD ne peut plus etre utilisee pour desactiver cette protection, qui est toujours activee. LD_PROFILE (depuis la glibc 2.1) The name of a (single) shared object to be profiled, specified either as a pathname or a soname. Profiling output is appended to the file whose name is: $LD_PROFILE_OUTPUT/ $LD_PROFILE.profile. Since glibc 2.2.5, LD_PROFILE uses a different default path in secure-execution mode. LD_PROFILE_OUTPUT (depuis la glibc 2.1) Repertoire ou sera ecrit le resultat de LD_PROFILE. Si cette variable n'est pas definie, ou si elle est definie a une valeur vide, le defaut est /var/tmp. LD_PROFILE_OUTPUT is ignored in secure-execution mode; instead /var/profile is always used. LD_SHOW_AUXV (depuis la glibc 2.1) Si cette variable d'environnement est definie (a n'importe quelle valeur), afficher le tableau auxiliaire transmis a partir du noyau (consulter aussi getauxval(3)). Depuis la glibc 2.3.4, LD_SHOW_AUXV est ignoree dans le mode d'execution securisee. LD_TRACE_PRELINKING (from glibc 2.4 to glibc 2.35) Si cette variable d'environnement est definie, tracer la pre-liaison de l'objet dont le nom est assigne a cette variable d'environnement. (Utiliser ldd(1) pour obtenir une liste des objets pouvant etre traces.) Si le nom d'objet n'est pas reconnu, alors l'activite de pre-liaison est tracee. LD_USE_LOAD_BIAS (from glibc 2.3.3 to glibc 2.35) Par defaut, c'est-a-dire si cette variable n'est pas definie, les executables et les objets partages pre-lies (prelink) respectent les adresses de base des objets partages dont ils dependent, alors que les executables PIE (position-independent executables) non pre-lies et les autres objets partages ne les respectent pas. Si LD_USE_LOAD_BIAS est definie a la valeur 1, les executables et les PIE vont respecter les adresses de base. Si LD_USE_LOAD_BIAS est definie a 0, ni les executables, ni les PIE ne respecteront les adresses de base. Depuis la glibc 2.3.3, cette variable est ignoree dans le mode d'execution securisee. LD_VERBOSE (depuis la glibc 2.1) S'il s'agit d'une chaine non vide, afficher les informations sur la version des symboles du programme si la variable d'environnement LD_TRACE_LOADED_OBJECTS a ete definie. LD_WARN (depuis la glibc 2.1.3) Si la chaine est non vide, avertir si un symbole n'est pas resolu. 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 prediction de branchement peuvent etre deteriorees quand la cible d'un branchement est situee a plus de 4 GB du branchement. Si cette variable d'environnement est definie (a n'importe quelle valeur), l'editeur de liens dynamiques essaie de mapper les pages d'executables en utilisant l'indicateur MAP_32BIT de mmap(2) et de revenir a un mappage sans cet indicateur si cet essai echoue. NB : MAP_32BIT mappera avec les 2 GB bas (pas 4 GB) de l'espace d'adressage. Parce que MAP_32BIT reduit l'eventail d'adressage pour la distribution aleatoire de l'espace d'adressage (ASLR), LD_PREFER_MAP_32BIT_EXEC est toujours desactivee dans le mode d'execution securisee. FICHIERS /lib/ld.so Le chargeur et editeur de liens dynamiques a.out. /lib/ld-linux.so.{1,2} Le chargeur et editeur de liens dynamiques ELF. /etc/ld.so.cache Fichier contenant la liste compilee des repertoires dans lesquels rechercher les objets partages et une liste d'objets partages candidats. Consulter ldconfig(8). /etc/ld.so.preload Fichier contenant une liste d'objets partages ELF, separes par des virgules, a charger avant le programme. Consultez le point a propos de LD_PRELOAD ci-dessus. Si LD_PRELOAD et /etc/ld.so.preload sont employes, la bibliotheque indiquee par LD_PRELOAD est prechargee en premier. /etc/ld.so.preload a un effet sur tout le systeme, faisant que les bibliotheques indiquees sont prechargees pour tous les programmes executes sur le systeme. (Cela est habituellement indesirable et employe uniquement comme remede d'urgence, par exemple, comme contournement temporaire d'un probleme de mauvaise configuration de bibliotheque.) lib*.so* Objets partages. NOTES Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37) Certains objets partages sont compiles en utilisant des instructions specifiques au materiel qui n'existent pas sur tous les processeurs. Ces objets devraient etre installes dans des repertoires dont les noms definissent les capacites materielles necessaires, comme /usr/lib/sse2/. L'editeur de liens dynamiques compare ces repertoires au materiel de la machine et selectionne la version la mieux adaptee pour un objet partage donne. Les repertoires de capacite materielle peuvent etre imbriques pour combiner les caracteristiques du microprocesseur. La liste des noms de capacite materielle pris en charge depend 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 The legacy hardware capabilities support has the drawback that each new feature added grows the search path exponentially, because it has to be added to every combination of the other existing features. For instance, on x86 32-bit, if the hardware supports i686 and sse2, the resulting search path will be i686/sse2:i686:sse2:.. A new capability newcap will set the search path to newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:. glibc Hardware capabilities (from glibc 2.33) glibc 2.33 added a new hardware capability scheme, where under each CPU architecture, certain levels can be defined, grouping support for certain features or special instructions. Each architecture level has a fixed set of paths that it adds to the dynamic linker search list, depending on the hardware of the machine. Since each new architecture level is not combined with previously existing ones, the new scheme does not have the drawback of growing the dynamic linker search list uncontrollably. For instance, on x86 64-bit, if the hardware supports x86_64-v3 (for instance Intel Haswell or AMD Excavator), the resulting search path will be glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. The following paths are currently supported, in priority order. PowerPC (64-bit little-endian only) power10, power9 s390 (64-bit only) z16, z15, z14, z13 x86 (64-bit only) x86-64-v4, x86-64-v3, x86-64-v2 glibc 2.37 removed support for the legacy hardware capabilities. 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 francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Jean-Paul Guillonneau Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 12 fevrier 2024 ld.so(8)