ld.so(8) System Manager's Manual ld.so(8) NOMBRE ld.so, ld-linux.so - enlazador/cargador dinamico SINOPSIS El enlazador dinamico puede ejecutarse bien indirectamente, al ejecutar un programa o biblioteca enlazado dinamicamente (en cuyo caso no pueden pasarse opciones en la linea de ordenes al enlazador dinamico y, en el caso del formato ELF, se ejecuta el enlazador dinamico que se encuentra almacenado en la seccion .interp del programa), bien directamente ejecutando: /lib/ld-linux.so.* [OPCIONES] [PROGRAMA [ARGUMENTOS]] DESCRIPCION Los programas ld.so y ld-linux.so* encuentran y cargan las bibliotecas compartidas requeridas por un programa, preparan al programa para ejecutarse y lo ejecutan. Los ficheros binarios en Linux requieren enlace dinamico (enlace en tiempo de ejecucion) a menos que se de la opcion - static a ld(1) durante la compilacion. El programa ld.so maneja ficheros binarios con el formato a.out, un formato usado hace tiempo. El programa ld-linux.so* maneja el formato ELF (/lib/ld-linux.so.1 para libc5, /lib/ld-linux.so.2 para glibc2), mas moderno. Por lo demas, ambos tienen el mismo comportamiento y usan los mismos ficheros de configuracion y programas (ldd(1), ldconfig(8) y /etc/ld.so.conf). Cuando se resuelven las dependencias de objetos compartidos, el enlazador dinamico empieza por comprobar cada dependencia para ver si contiene alguna barra (lo cual puede ocurrir si, al enlazar, definimos una ruta que contenia alguna). Si se encuentra una barra, la cadena se interpreta como un nombre de ruta (puede ser absoluto o relativo) y se cargara el objeto compartido con dicha ruta. Si la dependencia del objeto compartido no contiene ninguna barra, esta se buscara en este orden: (1) Se utilizan los directorios especificados en el atributo de seccion dinamica DT_RPATH del binario si esta y si no existe el atributo DT_RUNPATH. (2) Usando la variable de entorno LD_LIBRARY_PATH, salvo cuando se ejecute en modo seguro, en cuyo caso la variable sera ignorada. (3) Mediante los directorios definidos en el atributo de la seccion dinamica de DT_RUNPATH del binario, si existe. Solo se buscara en estos directorios los objetos requeridos en las entradas de DT_NEEDED (dependencias directas) pero no en los descendientes de estos objetos. Estos ultimos deben tener su propia entrada DT_RUNPATH. Esto es distinto de DT_RPATH, que se usa para buscar a todos los descendientes en el arbol de dependencias. (4) A partir del fichero de cache /etc/ld.so.cache, que contiene una lista compilada de bibliotecas candidatas encontradas previamente en la ruta de bibliotecas ampliada. Sin embargo, si el binario fue enlazado con la opcion -z nodefaultlib, se omitiran las bibliotecas que se encuentran en las rutas predeterminadas. Se prefieren los objetos compartidos instalados en directorios de capacidades de hardware (vea mas adelante) antes que los otros. (5) En las rutas por defecto: /lib y /usr/lib (en algunas arquitecturas de 64 bits, las rutas por defecto para estos objetos compartidos son /lib64 y /usr/lib64. Si el binario fue enlazado con la opcion -z nodefaultlib, se omite este paso. Token de cadena dinamica En varios lugares, el enlazador expandira los tokens de cadena dinamica: o En las variables de entorno LD_LIBRARY_PATH, LD_PRELOAD y LD_AUDIT, o en los valores de las etiquetas de seccion dinamica DT_NEEDED, DT_RPATH, DT_RUNPATH, DT_AUDIT y DT_DEPAUDIT, tambien binarios ELF, o en varios argumentos de la orden ld.so: --audit, --library-path y --preload, por ultimo o en el argumento del nombre de archivo de las funciones dlopen(3) y dlmopen(3). Los tokens sustituidos con como sigue: $ORIGIN (o el equivalente ${ORIGIN}) Esto se expandira con el directorio que contiene el programa o los objetos compartidos. Por lo tanto, una aplicacion que se encuentre en /dir/app se podria compilar con gcc -Wl,-rpath,'$ORIGIN/../lib' para que encuentre el objeto compartido en dir/lib pudiendo el directorio /dir estar localizado en cualquier punto del arbol de directorios. Esto evita que las aplicaciones deban instalarse en un directorios concreto sino que podran acceder a sus objetos compartidos desde cualquier directorio. $LIB (o su equivalente ${LIB}) Esto se interpretaria como lib o lib64 segun la arquitectura (logicamente si es x86-64 lo hara a lib64 y si es x86-32 lo hara a lib). $PLATFORM (o su equivalente ${PLATFORM}) Esto se expandira en una cadena de texto correspondiente al tipo de procesador del sistema (por ejemplo, "x86_64"). En algunas arquitecturas, el nucleo de Linux no proporciona una cadena de plataforma al enlazador dinamico. El valor de esta cadena se extrae de AT_PLATFORM en el vector auxiliar (consulte getauxval (3)). Observe que los tokens de cadena dinamicas tienen que entrecomillarse correctamente cuando se definen a traves de una shell para evitar que se interpreten como variables de entorno o de la propia shell. OPCIONES --preload list (a partir de glibc 2.33) Define el valor string para argv[0] antes de ejecutar la aplicacion. --audit lista Utilice los objetos nombrados en lista como auditores. Los objetos en lista ese delimitan entre si por dos puntos. --glibc-hwcaps-mask lista solo busca en los subdirectorios definidos si estan en lista. --glibc-hwcaps-prepend lista Busca los subdirectorios glibc-hwcaps de la lista --inhibit-cache No emplee /etc/ld.so.cache. --library-path ruta Emplee path en lugar de la configuracion de la variable de entorno LD_LIBRARY_PATH (vea mas adelante). Los nombres ORIGIN, LIB y PLATFORM se entienden dirigidos a la variable LD_LIBRARY_PATH. --inhibit-rpath lista Ignora la informacion de RPATH y RUNPATH en los nombres de objeto en list. Esta opcion se ignora si la ejecucion se realiza en modo seguro (vea mas adelante). Los objetos de la lista se separan mediante espacio o con dos puntos. --list Lista todas las dependencias y como se resuelven. --list-diagnostics (a partir de glibc 2.33) Muestra informacion de diagnostico del sistema en formato no legible por humanos: por ejemplo algunas variables internas del cargador, el vector auxiliar (vease getauxval(3)) y las variables de entorno. En algunas arquitecturas, la orden puede mostrar informacion adicional (como las caracteristicas de la cpu usadas en la seleccion indirecta de funciones GNU en x86). --list-tunables (desde glibc 2.33) muestra los nombres y valores de todas las variables, junto con los valores minimo y maximo permitidos. --preload list (a partir de glibc 2.30) Carga previamente los objetos especificados en list, separados entre si por dos puntos o por espacios. Estos objetos se cargaran previamente tal como se explica mas adelante en la descripcion de la variable LD_PRELOAD. Contrariamente al use de LD_PRELOAD, la opcion --preload permite realizar una carga previa para un solo ejecutable sin afectar a las cargas de otras procesos hijos de este que ejecuten un nuevo programa. --verify Comprueba que el programa esta enlazado dinamicamente y que el enlazador dinamico puede tratarlo. ENTORNO Diversas variables de entorno influyen en el funcionamiento del enlazador. Modo de ejecucion seguro Por razones de seguridad, si el enlazador dinamico determina que un binario debe ejecutarse en modo de ejecucion segura, se anularan los efectos de algunas variables de entorno, ademas esas variables se eliminan del entorno, de forma que el programa ni siquiera las ve. Algunas de estas variables de entorno afectan al funcionamiento del propio enlazador dinamico, y se describen a continuacion. Otras variables de entorno tratadas de esta manera incluyen 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, y TZDIR. Un binario se ejecuta en modo seguro si la entrada AT_SECURE en el vector auxiliar (consulte getauxval (3)) tiene un valor distinto de cero. Esta entrada puede tener un valor distinto de cero por varias razones: o Si difieren las ID de usuario reales y efectivas del proceso o las ID de grupo reales y efectivas. Esto suele ocurrir como resultado de la ejecucion de una apliacion con los bits activados de set-user-ID or set-group-ID. o Un proceso ejecutado por un usuario distinto al administrador ejecuta un binario que confiere alguna capacidad al mismo. o Es posible que un modulo de seguridad de Linux haya definido un valor distinto de cero. Variables de entorno Las variables de entorno mas relevantes son las siguientes: LD_ASSUME_KERNEL (desde glibc 2.2.3 hasta glibc 2.36) Cada objeto compartido puede indicarle al enlazador dinamico la version minima de ABI del nucleo que requiere. Este requisito esta codificado en una seccion de notas ELF que se puede ver mediante readelf -n en una seccion etiquetada como NT_GNU_ABI_TAG. Al ejecutarse, el enlazador dinamico determina la version de ABI del nucleo en ejecucion y rechazara la carga de objetos compartidos que especifiquen versiones minimas de ABI mayores que esa version de ABI. LD_ASSUME_KERNEL puede usarse para hacer que el enlazador dinamico asuma que se esta ejecutando en un sistema con una version de ABI de nucleo diferente. Por ejemplo, la siguiente orden hace que el enlazador dinamico asuma que se esta ejecutando en Linux 2.2.5 al cargar los objetos compartidos requeridos por myprog: $ LD_ASSUME_KERNEL=2.2.5 ./myprog En sistemas que proporcionan multiples versiones de un objeto compartido (en diferentes directorios en la ruta de busqueda) que tienen diferentes requisitos minimos de version de ABI del kernel, se puede usar LD_ASSUME_KERNEL para seleccionar la version del objeto que se usa (dependiendo del orden de busqueda del directorio). Historicamente, el uso mas comun de la funcion LD_ASSUME_KERNEL era seleccionar manualmente los antiguos subprocesos POSIX de LinuxThreads en sistemas que proporcionaban tanto LinuxThreads como NPTL (que normalmente era el predeterminado); consulte pthreads (7). LD_BIND_NOW (desde glibc 2.1.1) Si su valor es distinto de cero, hara que el enlazador dinamico resuelva todos los simbolos al iniciarse el programa en lugar de hacerlo la primera vez que se hace referencia a ellos. Esto es especialmente util cuando estamos usando un depurador. LD_LIBRARY_PATH Lista de directorios donde encontrar librerias ELF durante la ejecucion. Los componentes de la lista estaran separados entre si o bien por punto y coma o bien por dos puntos no siendo posible usar una secuencia de escape para ninguno de ellos. Si la longitud del nombre del directorio es cero, se entendera el directorio actual. Esta variable se ignora en el modo de ejecucion seguro. Dentro de los nombres de ruta especificados en LD_LIBRARY_PATH, el enlazador dinamico expande los tokens $ ORIGIN, $ LIB e $ PLATFORM (o las versiones que usan llaves alrededor de los nombres) como se ha descrito anteriormente en Tokens de cadena dinamica. Por ejemplo, para buscar una biblioteca en el subdirectorio lib o lib64 dentro del directorio que contiene el programa a ejecutar: $ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog (Observe el uso de comillas simples para evitar que la shell interprete $ORIGIN y $LIB como variables) LD_PRELOAD Una lista con una serie adicional, especificados por el usuario, de objetos compartidos ELF para ser cargados antes que todos los demas. Esto puede usarse para anular en casos concretos algunas funciones en otros objetos compartidos. Los componentes de esta lista puede separarse entre si mediante dos puntos o mediante punto y coma. No existe una secuencia de escape para estos dos caracteres. Se buscan los objetos empleando la regla definida en DESCRIPTION, se van anadiendo al mapa de enlaces de izquierda a derecha segun se especifica en la lista. En el modo de ejecucion seguro, se ignoran los nombres de ruta de precarga si contienen barras. Ademas, los objetos compartidos se precargan solo desde los directorios de busqueda estandar y solo si tienen habilitado el bit set-user-ID (lo cual no es habitual). Dentro de los nombres especificados en la lista LD_PRELOAD, el enlazador dinamico interpreta los tokens $ ORIGIN, $ LIB e $ PLATFORM (o los equivalente con llaves alrededor de los nombres) como se ha descrito anteriormente en tokens de cadena dinamica. (Vease tambien la explicacion sobre el entrecomillado en el apartado LD_LIBRARY_PATH.) Existen varias formas de indicar las bibliotecas que se deben precargar, siguiendo este orden: (1) La variable de entorno LD_PRELOAD. (2) Indicar en la linea de ordenes la opcion --preload cuando se ejecute directamente el enlazador dinamico. (3) Desde el archivo /etc/ld.so.preload (explicado mas adelante). LD_TRACE_LOADED_OBJECTS Si esta definido (cualquiera que sea su valor) hara que el programa liste sus dependencias como si fuese ejecutado por ldd(1) en lugar de directamente. Hay muchas mas variables mas o menos cripticas, muchas de ellas anticuadas o para uso interno. LD_AUDIT (desde glibc 2.4) Una lista de objetos compartidos ELF especificados por el usuario que se cargaran antes que todos los demas en un espacio de nombres de enlazador separado (es decir, uno que no interfiera en el enlazado de simbolos del proceso) Estos objetos se pueden usar para auditar la operacion del enlazador dinamico. Los elementos de la lista estan separados entre si por dos puntos y no existe ninguna secuencia de escape para este separador. Se ignora LD_AUDIT en el modo de ejecucion seguro. El enlazador dinamico notificara a los objetos compartidos de auditoria en los llamados puntos de control de auditoria, por ejemplo, cargando un nuevo objeto compartido, resolviendo un simbolo o llamando a un simbolo de otro objeto compartido (llamando a una funcion apropiada dentro del objeto compartido de auditoria). Para obtener mas informacion, consulte rtld-audit (7) La interfaz de auditoria es en gran medida compatible con la proporcionada en Solaris, como se describe en su Linker and Libraries Guide, en el capitulo Runtime Linker Auditing Interface. Dentro de los nombres especificados en la lista LD_AUDIT, el enlazador dinamico interpreta los tokens $ ORIGIN, $ LIB e $ PLATFORM (o los equivalentes con llaves alrededor de los nombres) como se ha descrito anteriormente en tokens de cadena dinamica. (Vease tambien la explicacion del entrecomillado en el apartado LD_LIBRARY_PATH.) A partir de la version 2.13 de glibc, en el modo de ejecucion segura, los nombres de la lista de auditoria que contienen barras se ignoran y solo se cargan los objetos compartidos en los directorios de busqueda estandar que tienen habilitado el bit set-user-ID. LD_BIND_NOT (a partir de glibc 2.1.95) Si esta variable de entorno se establece en una cadena no vacia, no actualiza GOT (tabla de compensacion global) y PLT (tabla de vinculacion de procedimientos) despues de resolver un simbolo de funcion. Si con el uso de esta variable, anadimos LD_DEBUG (con las categorias bindings y symbols), se pueden observar todos los enlaces de funciones en tiempo de ejecucion. LD_DEBUG (desde glibc 2.1) Muestra informacion detallada de depuracion sobre el funcionamiento del enlazador dinamico. El contenido de esta variable es una o mas de las siguientes categorias, separadas por dos puntos, comas o (si se entrecomilla el valor) espacios: help Si asignamos el valor help a esta variable, no se ejecutara el programa y se mostrara un mensaje de ayuda informando acerca de las categorias que se pueden definir en esta variable de entorno. all Imprime informacion para la depuracion (salvo statistics ni unused; vea a continuacion. bindings Muestra informacion sobre la definicion a la que esta vinculado cada simbolo. files Muestra el progreso del archivo de entrada. libs Muestra las rutas de busqueda de las librerias. reloc Muestra el procesamiento de reubicacion. scopes Muestra informacion del alcance. statistics Muestra estadisticas de reubicacion. symbols Muestra las rutas de busqueda para cada busqueda de simbolo. unused Determina los DSO's sin usar. versions Muestra las dependencias de esa version. Desde glibc 2.3.4, LD_DEBUG se ignora en el modo de ejecucion segura, salvo que exista el archivo /etc/suid-debug (el contenido del archivo es irrelevante). LD_DEBUG_OUTPUT (desde glibc 2.1) Por defecto, la salida LD_DEBUG se escribe a error estandar. Si se define LD_DEBUG_OUTPUT, la salida se escribe en el nombre de ruta especificado por su valor, con el sufijo "." (punto) seguido del ID de proceso adjunto al nombre de la ruta. LD_DEBUG_OUTPUT se ignora en el modo de ejecucion seguro. LD_DYNAMIC_WEAK (desde glibc 2.1.91) Por defecto, cuando el enlazador busque una biblioteca compartida para encontrar algun simbolo, tomara la primera definicion que encuentre. Las versiones de glibc anteriores a 2.2, lo hacian de otro modo: si el enlazador encontraba un simbolo debil, seguiria buscando hasta encontrar uno mas fuerte en el resto de bibliotecas compartidas. Si encontrase uno mas fuerte, lo usaria.En caso de no encontrar otro mas fuerte, usaria la definicion del debil. Si no se encontrasen mas simbolos, el enlazador dinamico usuara el simbolo debil encontrado al inicio El antiguo comportamiento de glibc no era el estandar. (La practica estandarizada es que la distincion entre simbolos debiles y fuertes deberia tener efecto solo durante del enlazado estatico). En glibc 2.2, el enlazador dinamico se modifico para tener el comportamiento actual, que era el comportamiento que ya proporcionaban la mayoria de las otras implementaciones. Si se define la variable de entorno LD_DYNAMIC_WEAK (con cualquier valor) se tendra el antiguo comportamiento glibc (no estandar), mediante el cual un simbolo debil en una biblioteca compartida puede ser anulado por un simbolo fuerte posteriormente descubierto en otra biblioteca compartida. (Observe que incluso cuando se establece esta variable, un simbolo fuerte en una biblioteca compartida no anulara una definicion debil del mismo simbolo en el programa principal). A partir de glibc 2.3.4, LD_DYNAMIC_WEAK se ignora en el modo de ejecucion seguro. LD_HWCAP_MASK (desde glibc 2.1 hasta glibc 2.38) Mascara para capacidades de hardware. A partir de la version 2.26 de glibc, la opcion puede ser ignorada si glibc no incluye soporte para tunables. LD_ORIGIN_PATH (desde glibc 2.1) Ruta donde se encuentra el binario. A partir de glibc 2.4, LD_ORIGIN_PATH se ignora en el modo de ejecucion seguro. LD_POINTER_GUARD (glibc desde la version 2.4 hasta la 2.22) Definir a 0 para deshabilitar la proteccion del puntero. Cualquier otro valor habilita la proteccion del puntero (lo hara por defecto). La proteccion de punteros es un mecanismo de seguridad mediante el cual se alteran de forma semi-aleatoria el codigo almacenado en la memoria del programa grabable (devuelven direcciones guardads por setjmp(3) o punteros de funcion utilizados por varios componentes internos de glibc) para dificultar que un atacante puede usarlos si se produce un desbordamiento de bufer o un ataque a la pila. Desde la version 2.23 de glibc, LD_POINTER_GUARD ya no se puede deshabilitar la proteccion de punteros. LD_PROFILE (a partir de glibc 2.1) El nombre de un objeto compartido (unico) que se va a perfilar, especificado como nombre de ruta o como soname. La salida del perfilado se agrega al archivo cuyo nombre es: LD_PROFILE_OUTPUT/$ LD_PROFILE.profile . Desde glibc 2.2.5, LD_PROFILE utiliza una ruta predeterminada diferente en el modo de ejecucion segura. LD_PROFILE_OUTPUT (desde glibc 2.1) Directorio donde se debe escribir la salida de LD_PROFILE. Si esta variable no esta definida, o esta definida como una cadena vacia, se toma por defecto /var/tmp. LD_PROFILE_OUTPUT se ignora en modo de ejecucion segura; en su lugar se utiliza siempre /var/profile. LD_SHOW_AUXV (desde glibc 2.1) Si esta variable de entorno esta definida (con cualquier valor), muestra la matriz auxiliar enviada desde el nucleo (vea tambien getauxval (3)). A partir de glibc 2.3.4, LD_SHOW_AUXV se ignora en el modo de ejecucion seguro. LD_TRACE_PRELINKING (desde glibc 2.4 hasta glibc 2.35) Si se define esta variable de entorno, se hara un seguimiento de la vinculacion previa del objeto cuyo nombre esta asignado a esta variable de entorno. (Utilice ldd (1) para ver los objetos que se pueden rastrear.) Si no se reconoce el nombre del objeto, se rastrea toda la actividad de preenlace. LD_USE_LOAD_BIAS (desde glibc 2.3.3 hasta glibc 2.35) De forma predeterminada (es decir, si esta variable no esta definida), los ejecutables y los objetos compartidos preenlazados respetaran las direcciones base de sus objetos compartidos dependientes, pero los ejecutables independientes de la posicion (PIE) (no vinculados previamente) y otros objetos compartidos no los respetaran. Si LD_USE_LOAD_BIAS se define con el valor 1, tanto los ejecutables como los PIE respetaran las direcciones base. Si LD_USE_LOAD_BIAS se define con el valor 0, ni los ejecutables ni los PIE respetaran las direcciones base. A partir de glibc 2.3.3 se ignora esta variable en el modo de ejecucion seguro. LD_VERBOSE (a partir de glibc 2.1) Si se le asigna un valor de una cadena no vacia y si se ha establecido la variable de entorno LD_TRACE_LOADED_OBJECTS, se generara informacion sobre la version del simbolo sobre el programa. LD_WARN (desde glibc 2.1.3) Si se le asigna como valor una cadena no nula, avisara si detecta simbolos no resueltos. LD_PREFER_MAP_32BIT_EXEC (solo en x86-64 y desde glibc 2.23) Segun la guia de optimizacion del software Intel Silvermont, para las aplicaciones de 64 bits, el rendimiento de la prediccion de ramas puede verse afectado negativamente cuando el objetivo de una rama esta a mas de 4 GB de distancia de ella. Si esta variable de entorno esta configurada (con cualquier valor), el enlazador dinamico primero intentara mapear paginas ejecutables usando mmap (2) MAP_32BIT y volvera a mapear si ese intento falla. NB: MAP_32BIT se asignara a los 2 GB (no 4 GB) del espacio de direcciones. Debido a que MAP_32BIT reduce el rango de direcciones disponible para que el diseno del espacio de direcciones sea aleatorio (ASLR), LD_PREFER_MAP_32BIT_EXEC siempre esta deshabilitado en el modo de ejecucion segura. ARCHIVOS /lib/ld.so enlazador/cargador dinmico /lib/ld-linux.so.{1,2} Enlazador/cargador dinamico ELF /etc/ld.so.cache Archivo que contiene una lista de directorios donde encontrar objetos compartidos y una lista ordenada de los candidatos. Consulte ldconfig(8). /etc/ld.so.preload Archivo que contiene una lista de objetos compartidos ELF separados entre si por espacios en blanco que se cargaran antes del programa. Vea el apartado anterior LD_PRELOAD. Si se emplean tanto LD_PRELOAD como /etc/ld.so.preload, las bibliotecas especificadas por LD_PRELOAD se precargan primero. /etc/ld.so.preload tiene efecto en todo el sistema, lo que hace que las bibliotecas especificadas se carguen previamente para todos los programas que se ejecutan en el sistema. (En general, no suele ser una opcion ideal y por lo tanto, solo se emplea como una solucion de emergencia, por ejemplo, como una solucion temporal para un problema de configuracion incorrecta de la biblioteca). lib*.so* objetos compartidos NOTAS Capacidades hardware anticuadas (a partir de glibc 2.5 hasta 2.37) Algunos objetos compartidos se compilan utilizando instrucciones especificas de hardware que no existen en todas las CPU. Estos objetos deben instalarse en directorios cuyos nombres definan las capacidades de hardware necesarias, como /usr /lib/sse2/. El enlazador dinamico compara estos directorios con el hardware de la maquina y selecciona la version mas adecuada de un objeto compartido dado. Los directorios de capacidad de hardware se pueden conectar en cascada para combinar funciones de CPU. La lista de nombres de capacidad de hardware admitidos depende de la CPU. Actualmente se reconocen los siguientes: 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 (solo 32-bit) 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 La compatibilidad con las capacidades de hardware antiguas tiene el inconveniente de que cada nueva funcion anadida hace crecer exponencialmente la ruta de busqueda, porque hay que anadirla a cada combinacion de las demas funciones existentes. Por ejemplo, en x86 de 32 bits, si el hardware admite i686 y sse2, la ruta de busqueda resultante sera i686/sse2:i686:sse2:.. Una nueva capacidad newcap estableceria la ruta de busqueda en newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:. Capacidad de hardware de glibc (a partir de glibc 2.33) glibc 2.33 anadio un nuevo esquema de capcidades de hardware donde bajo cada arquitectura de CPU, se pueden definir ciertos niveles, agrupando el soporte para ciertas caracteristicas o instrucciones especiales. Cada nivel de arquitectura tiene un conjunto fijo de rutas que anade a la lista de busqueda del enlazador dinamico, en funcion del hardware del equipo. Dado que cada nuevo nivel de arquitectura no se combina con otros ya existentes, el nuevo esquema ya no tiene el inconveniente de hacer crecer de forma incontrolada la lista de busqueda del enlazador dinamico. Por ejemplo, en x86 de 64 bits, si el hardware admite x86_64-v3 (por ejemplo, Intel Haswell o AMD Excavator), la ruta de busqueda resultante sera glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. Actualmente se admiten las siguientes rutas, por orden de prioridad: PowerPC (64-bit solo little-endian) power10, power9 s390 (solo 64-bit) z16, z15, z14, z13 x86 (solo 64-bit) x86-64-v4, x86-64-v3, x86-64-v2 glibc 2.37 elimino el soporte para las capacidades de hardware antiguas. VEASE TAMBIEN ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5), capabilities(7), rtld-audit(7), ldconfig(8), sln(8) TRADUCCION La traduccion al espanol de esta pagina del manual fue creada por Juan Piernas y Marcos Fouces Esta traduccion es documentacion libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. Si encuentra algun error en la traduccion de esta pagina del manual, envie un correo electronico a . Paginas de Manual de Linux 6.8 8 Mayo 2024 ld.so(8)