diff options
Diffstat (limited to 'man/man8/ld.so.8')
| -rw-r--r-- | man/man8/ld.so.8 | 930 |
1 files changed, 930 insertions, 0 deletions
diff --git a/man/man8/ld.so.8 b/man/man8/ld.so.8 new file mode 100644 index 000000000..fa75b7820 --- /dev/null +++ b/man/man8/ld.so.8 @@ -0,0 +1,930 @@ +.\" %%%LICENSE_START(PUBLIC_DOMAIN) +.\" This is in the public domain +.\" %%%LICENSE_END +.\" Various parts: +.\" Copyright (C) 2007-9, 2013, 2016 Michael Kerrisk <mtk.manpages@gmail.com> +.\" +.TH ld.so 8 (date) "Linux man-pages (unreleased)" +.SH NAME +ld.so, ld\-linux.so \- dynamic linker/loader +.SH SYNOPSIS +The dynamic linker can be run either indirectly by running some +dynamically linked program or shared object +(in which case no command-line options +to the dynamic linker can be passed and, in the ELF case, the dynamic linker +which is stored in the +.B .interp +section of the program is executed) or directly by running: +.P +.I /lib/ld\-linux.so.* +[OPTIONS] [PROGRAM [ARGUMENTS]] +.SH DESCRIPTION +The programs +.B ld.so +and +.B ld\-linux.so* +find and load the shared objects (shared libraries) needed by a program, +prepare the program to run, and then run it. +.P +Linux binaries require dynamic linking (linking at run time) +unless the +.B \-static +option was given to +.BR ld (1) +during compilation. +.P +The program +.B ld.so +handles a.out binaries, a binary format used long ago. +The program +.B ld\-linux.so* +(\fI/lib/ld\-linux.so.1\fP for libc5, \fI/lib/ld\-linux.so.2\fP for glibc2) +handles binaries that are in the more modern ELF format. +Both programs have the same behavior, and use the same +support files and programs +.RB ( ldd (1), +.BR ldconfig (8), +and +.IR /etc/ld.so.conf ). +.P +When resolving shared object dependencies, +the dynamic linker first inspects each dependency +string to see if it contains a slash (this can occur if +a shared object pathname containing slashes was specified at link time). +If a slash is found, then the dependency string is interpreted as +a (relative or absolute) pathname, +and the shared object is loaded using that pathname. +.P +If a shared object dependency does not contain a slash, +then it is searched for in the following order: +.IP (1) 5 +Using the directories specified in the +DT_RPATH dynamic section attribute +of the binary if present and DT_RUNPATH attribute does not exist. +Use of DT_RPATH is deprecated. +.IP (2) +Using the environment variable +.BR LD_LIBRARY_PATH , +unless the executable is being run in secure-execution mode (see below), +in which case this variable is ignored. +.IP (3) +Using the directories specified in the +DT_RUNPATH dynamic section attribute +of the binary if present. +Such directories are searched only to +find those objects required by DT_NEEDED (direct dependencies) entries +and do not apply to those objects' children, +which must themselves have their own DT_RUNPATH entries. +This is unlike DT_RPATH, which is applied +to searches for all children in the dependency tree. +.IP (4) +From the cache file +.IR /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 +.B \-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. +.IP (5) +In the default path +.IR /lib , +and then +.IR /usr/lib . +(On some 64-bit architectures, the default paths for 64-bit shared objects are +.IR /lib64 , +and then +.IR /usr/lib64 .) +If the binary was linked with the +.B \-z nodefaultlib +linker option, this step is skipped. +.\" +.SS Dynamic string tokens +In several places, the dynamic linker expands dynamic string tokens: +.IP \[bu] 3 +In the environment variables +.BR LD_LIBRARY_PATH , +.BR LD_PRELOAD , +and +.BR LD_AUDIT , +.IP \[bu] +inside the values of the dynamic section tags +.BR DT_NEEDED , +.BR DT_RPATH , +.BR DT_RUNPATH , +.BR DT_AUDIT , +and +.B DT_DEPAUDIT +of ELF binaries, +.IP \[bu] +in the arguments to the +.B ld.so +command line options +.BR \-\-audit , +.BR \-\-library\-path , +and +.B \-\-preload +(see below), and +.IP \[bu] +in the filename arguments to the +.BR dlopen (3) +and +.BR dlmopen (3) +functions. +.P +The substituted tokens are as follows: +.TP +.IR $ORIGIN " (or equivalently " ${ORIGIN} ) +This expands to +the directory containing the program or shared object. +Thus, an application located in +.I somedir/app +could be compiled with +.IP +.in +4n +.EX +gcc \-Wl,\-rpath,\[aq]$ORIGIN/../lib\[aq] +.EE +.in +.IP +so that it finds an associated shared object in +.I somedir/lib +no matter where +.I somedir +is located in the directory hierarchy. +This facilitates the creation of "turn-key" applications that +do not need to be installed into special directories, +but can instead be unpacked into any directory +and still find their own shared objects. +.TP +.IR $LIB " (or equivalently " ${LIB} ) +This expands to +.I lib +or +.I lib64 +depending on the architecture +(e.g., on x86-64, it expands to +.I lib64 +and +on x86-32, it expands to +.IR lib ). +.TP +.IR $PLATFORM " (or equivalently " ${PLATFORM} ) +This expands to a string corresponding to the processor type +of the host system (e.g., "x86_64"). +On some architectures, the Linux kernel doesn't provide a platform +string to the dynamic linker. +The value of this string is taken from the +.B AT_PLATFORM +value in the auxiliary vector (see +.BR getauxval (3)). +.\" To get an idea of the places that $PLATFORM would match, +.\" look at the output of the following: +.\" +.\" mkdir /tmp/d +.\" LD_LIBRARY_PATH=/tmp/d strace -e open /bin/date 2>&1 | grep /tmp/d +.\" +.\" ld.so lets names be abbreviated, so $O will work for $ORIGIN; +.\" Don't do this!! +.P +Note that the dynamic string tokens have to be quoted properly when +set from a shell, +to prevent their expansion as shell or environment variables. +.SH OPTIONS +.TP +.BR \-\-argv0 " \fIstring\fP (since glibc 2.33)" +Set +.I argv[0] +to the value +.I string +before running the program. +.TP +.BI \-\-audit " list" +Use objects named in +.I list +as auditors. +The objects in +.I list +are delimited by colons. +.TP +.BI \-\-glibc-hwcaps-mask " list" +only search built-in subdirectories if in +.IR list . +.TP +.BI \-\-glibc-hwcaps-prepend " list" +Search glibc-hwcaps subdirectories in +.IR list . +.TP +.B \-\-inhibit\-cache +Do not use +.IR /etc/ld.so.cache . +.TP +.BI \-\-library\-path " path" +Use +.I path +instead of +.B LD_LIBRARY_PATH +environment variable setting (see below). +The names +.IR ORIGIN , +.IR LIB , +and +.I PLATFORM +are interpreted as for the +.B LD_LIBRARY_PATH +environment variable. +.TP +.BI \-\-inhibit\-rpath " list" +Ignore RPATH and RUNPATH information in object names in +.IR list . +This option is ignored when running in secure-execution mode (see below). +The objects in +.I list +are delimited by colons or spaces. +.TP +.B \-\-list +List all dependencies and how they are resolved. +.TP +.BR \-\-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 +.BR 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). +.BR \-\-list\-tunables " (since glibc 2.33)" +Print the names and values of all tunables, +along with the minimum and maximum allowed values. +.TP +.BR \-\-preload " \fIlist\fP (since glibc 2.30)" +Preload the objects specified in +.IR list . +The objects in +.I list +are delimited by colons or spaces. +The objects are preloaded as explained in the description of the +.B LD_PRELOAD +environment variable below. +.IP +By contrast with +.BR LD_PRELOAD , +the +.B \-\-preload +option provides a way to perform preloading for a single executable +without affecting preloading performed in any child process that executes +a new program. +.TP +.B \-\-verify +Verify that program is dynamically linked and this dynamic linker can handle +it. +.SH ENVIRONMENT +Various environment variables influence the operation of the dynamic linker. +.\" +.SS Secure-execution mode +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: +.BR GCONV_PATH , +.BR GETCONF_DIR , +.BR HOSTALIASES , +.BR LOCALDOMAIN , +.BR LD_AUDIT , +.BR LD_DEBUG , +.BR LD_DEBUG_OUTPUT , +.BR LD_DYNAMIC_WEAK , +.BR LD_HWCAP_MASK , +.BR LD_LIBRARY_PATH , +.BR LD_ORIGIN_PATH , +.BR LD_PRELOAD , +.BR LD_PROFILE , +.BR LD_SHOW_AUXV , +.BR LOCALDOMAIN , +.BR LOCPATH , +.BR MALLOC_TRACE , +.BR NIS_PATH , +.BR NLSPATH , +.BR RESOLV_HOST_CONF , +.BR RES_OPTIONS , +.BR TMPDIR , +and +.BR TZDIR . +.P +A binary is executed in secure-execution mode if the +.B AT_SECURE +entry in the auxiliary vector (see +.BR getauxval (3)) +has a nonzero value. +This entry may have a nonzero value for various reasons, including: +.IP \[bu] 3 +The process's real and effective user IDs differ, +or the real and effective group IDs differ. +This typically occurs as a result of executing +a set-user-ID or set-group-ID program. +.IP \[bu] +A process with a non-root user ID executed a binary that +conferred capabilities to the process. +.IP \[bu] +A nonzero value may have been set by a Linux Security Module. +.\" +.SS Environment variables +Among the more important environment variables are the following: +.TP +.BR 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 +.I readelf\~\-n +as a section labeled +.BR 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. +.IP +.B LD_ASSUME_KERNEL +can be used to +cause the dynamic linker to assume that it is running on a system with +a different kernel ABI version. +For example, the following command line causes the +dynamic linker to assume it is running on Linux 2.2.5 when loading +the shared objects required by +.IR myprog : +.IP +.in +4n +.EX +$ \fBLD_ASSUME_KERNEL=2.2.5 ./myprog\fP +.EE +.in +.IP +On systems that provide multiple versions of a shared object +(in different directories in the search path) that have +different minimum kernel ABI version requirements, +.B LD_ASSUME_KERNEL +can be used to select the version of the object that is used +(dependent on the directory search order). +.IP +Historically, the most common use of the +.B LD_ASSUME_KERNEL +feature was to manually select the older +LinuxThreads POSIX threads implementation on systems that provided both +LinuxThreads and NPTL +(which latter was typically the default on such systems); +see +.BR pthreads (7). +.TP +.BR LD_BIND_NOW " (since glibc 2.1.1)" +If set to a nonempty string, +causes the dynamic linker to resolve all symbols +at program startup instead of deferring function call resolution to the point +when they are first referenced. +This is useful when using a debugger. +.TP +.B LD_LIBRARY_PATH +A list of directories in which to search for +ELF libraries at execution time. +The items in the list are separated by either colons or semicolons, +and there is no support for escaping either separator. +A zero-length directory name indicates the current working directory. +.IP +This variable is ignored in secure-execution mode. +.IP +Within the pathnames specified in +.BR LD_LIBRARY_PATH , +the dynamic linker expands the tokens +.IR $ORIGIN , +.IR $LIB , +and +.I $PLATFORM +(or the versions using curly braces around the names) +as described above in +.IR "Dynamic string tokens" . +Thus, for example, +the following would cause a library to be searched for in either the +.I lib +or +.I lib64 +subdirectory below the directory containing the program to be executed: +.IP +.in +4n +.EX +$ \fBLD_LIBRARY_PATH=\[aq]$ORIGIN/$LIB\[aq] prog\fP +.EE +.in +.IP +(Note the use of single quotes, which prevent expansion of +.I $ORIGIN +and +.I $LIB +as shell variables!) +.TP +.B LD_PRELOAD +A list of additional, user-specified, ELF shared +objects to be loaded before all others. +This feature can be used to selectively override functions +in other shared objects. +.IP +The items of the list can be separated by spaces or colons, +and there is no support for escaping either separator. +The objects are searched for using the rules given under DESCRIPTION. +Objects are searched for and added to the link map in the left-to-right +order specified in the list. +.IP +In secure-execution mode, +preload pathnames containing slashes are ignored. +Furthermore, shared objects are preloaded only +from the standard search directories and only +if they have set-user-ID mode bit enabled (which is not typical). +.IP +Within the names specified in the +.B LD_PRELOAD +list, the dynamic linker understands the tokens +.IR $ORIGIN , +.IR $LIB , +and +.I $PLATFORM +(or the versions using curly braces around the names) +as described above in +.IR "Dynamic string tokens" . +(See also the discussion of quoting under the description of +.BR LD_LIBRARY_PATH .) +.\" Tested with the following: +.\" +.\" LD_PRELOAD='$LIB/libmod.so' LD_LIBRARY_PATH=. ./prog +.\" +.\" which will preload the libmod.so in 'lib' or 'lib64', using it +.\" in preference to the version in '.'. +.IP +There are various methods of specifying libraries to be preloaded, +and these are handled in the following order: +.RS +.IP (1) 5 +The +.B LD_PRELOAD +environment variable. +.IP (2) +The +.B \-\-preload +command-line option when invoking the dynamic linker directly. +.IP (3) +The +.I /etc/ld.so.preload +file (described below). +.RE +.TP +.B LD_TRACE_LOADED_OBJECTS +If set (to any value), causes the program to list its dynamic +dependencies, as if run by +.BR ldd (1), +instead of running normally. +.P +Then there are lots of more or less obscure variables, +many obsolete or only for internal use. +.TP +.BR LD_AUDIT " (since glibc 2.4)" +A list of user-specified, ELF shared objects +to be loaded before all others in a separate linker namespace +(i.e., one that does not intrude upon the normal symbol bindings that +would occur in the process) +These objects can be used to audit the operation of the dynamic linker. +The items in the list are colon-separated, +and there is no support for escaping the separator. +.IP +.B LD_AUDIT +is ignored in secure-execution mode. +.IP +The dynamic linker will notify the audit +shared objects at so-called auditing checkpoints\[em]for example, +loading a new shared object, resolving a symbol, +or calling a symbol from another shared object\[em]by +calling an appropriate function within the audit shared object. +For details, see +.BR rtld\-audit (7). +The auditing interface is largely compatible with that provided on Solaris, +as described in its +.IR "Linker and Libraries Guide" , +in the chapter +.IR "Runtime Linker Auditing Interface" . +.IP +Within the names specified in the +.B LD_AUDIT +list, the dynamic linker understands the tokens +.IR $ORIGIN , +.IR $LIB , +and +.I $PLATFORM +(or the versions using curly braces around the names) +as described above in +.IR "Dynamic string tokens" . +(See also the discussion of quoting under the description of +.BR LD_LIBRARY_PATH .) +.IP +Since glibc 2.13, +.\" commit 8e9f92e9d5d7737afdacf79b76d98c4c42980508 +in secure-execution mode, +names in the audit list that contain slashes are ignored, +and only shared objects in the standard search directories that +have the set-user-ID mode bit enabled are loaded. +.TP +.BR LD_BIND_NOT " (since glibc 2.1.95)" +If this environment variable is set to a nonempty string, +do not update the GOT (global offset table) and PLT (procedure linkage table) +after resolving a function symbol. +By combining the use of this variable with +.B LD_DEBUG +(with the categories +.I bindings +and +.IR symbols ), +one can observe all run-time function bindings. +.TP +.BR LD_DEBUG " (since glibc 2.1)" +Output verbose debugging information about operation of the dynamic linker. +The content of this variable is one of more of the following categories, +separated by colons, commas, or (if the value is quoted) spaces: +.RS +.TP 12 +.I help +Specifying +.I help +in the value of this variable does not run the specified program, +and displays a help message about which categories can be specified in this +environment variable. +.TP +.I all +Print all debugging information (except +.I statistics +and +.IR unused ; +see below). +.TP +.I bindings +Display information about which definition each symbol is bound to. +.TP +.I files +Display progress for input file. +.TP +.I libs +Display library search paths. +.TP +.I reloc +Display relocation processing. +.TP +.I scopes +Display scope information. +.TP +.I statistics +Display relocation statistics. +.TP +.I symbols +Display search paths for each symbol look-up. +.TP +.I unused +Determine unused DSOs. +.TP +.I versions +Display version dependencies. +.RE +.IP +Since glibc 2.3.4, +.B LD_DEBUG +is ignored in secure-execution mode, unless the file +.I /etc/suid\-debug +exists (the content of the file is irrelevant). +.TP +.BR LD_DEBUG_OUTPUT " (since glibc 2.1)" +By default, +.B LD_DEBUG +output is written to standard error. +If +.B LD_DEBUG_OUTPUT +is defined, then output is written to the pathname specified by its value, +with the suffix "." (dot) followed by the process ID appended to the pathname. +.IP +.B LD_DEBUG_OUTPUT +is ignored in secure-execution mode. +.TP +.BR LD_DYNAMIC_WEAK " (since glibc 2.1.91)" +By default, when searching shared libraries to resolve a symbol reference, +the dynamic linker will resolve to the first definition it finds. +.IP +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.) +.IP +The old glibc behavior was nonstandard. +(Standard practice is that the distinction between +weak and strong symbols should have effect only at static link time.) +In glibc 2.2, +.\" More precisely 2.1.92 +.\" See weak handling +.\" https://www.sourceware.org/ml/libc-hacker/2000-06/msg00029.html +.\" To: GNU libc hacker <libc-hacker at sourceware dot cygnus dot com> +.\" Subject: weak handling +.\" From: Ulrich Drepper <drepper at redhat dot com> +.\" Date: 07 Jun 2000 20:08:12 -0700 +.\" Reply-To: drepper at cygnus dot com (Ulrich Drepper) +the dynamic linker was modified to provide the current behavior +(which was the behavior that was provided by most other implementations +at that time). +.IP +Defining the +.B LD_DYNAMIC_WEAK +environment variable (with any value) provides +the old (nonstandard) glibc behavior, +whereby a weak symbol in one shared library may be overridden by +a strong symbol subsequently discovered in another shared library. +(Note that even when this variable is set, +a strong symbol in a shared library will not override +a weak definition of the same symbol in the main program.) +.IP +Since glibc 2.3.4, +.B LD_DYNAMIC_WEAK +is ignored in secure-execution mode. +.TP +.BR 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. +.TP +.BR LD_ORIGIN_PATH " (since glibc 2.1)" +Path where the binary is found. +.\" Used only if $ORIGIN can't be determined by normal means +.\" (from the origin path saved at load time, or from /proc/self/exe)? +.IP +Since glibc 2.4, +.B LD_ORIGIN_PATH +is ignored in secure-execution mode. +.TP +.BR LD_POINTER_GUARD " (from glibc 2.4 to glibc 2.22)" +Set to 0 to disable pointer guarding. +Any other value enables pointer guarding, which is also the default. +Pointer guarding is a security mechanism whereby some pointers to code +stored in writable program memory (return addresses saved by +.BR setjmp (3) +or function pointers used by various glibc internals) are mangled +semi-randomly to make it more difficult for an attacker to hijack +the pointers for use in the event of a buffer overrun or +stack-smashing attack. +Since glibc 2.23, +.\" commit a014cecd82b71b70a6a843e250e06b541ad524f7 +.B LD_POINTER_GUARD +can no longer be used to disable pointer guarding, +which is now always enabled. +.TP +.BR LD_PROFILE " (since 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: +.RI \%$LD_PROFILE_OUTPUT /\: $LD_PROFILE .profile . +.IP +Since glibc 2.2.5, +.B LD_PROFILE +uses a different default path in secure-execution mode. +.TP +.BR LD_PROFILE_OUTPUT " (since glibc 2.1)" +Directory where +.B LD_PROFILE +output should be written. +If this variable is not defined, or is defined as an empty string, +then the default is +.IR /var/tmp . +.IP +.B LD_PROFILE_OUTPUT +is ignored in secure-execution mode; instead +.I /var/profile +is always used. +.TP +.BR LD_SHOW_AUXV " (since glibc 2.1)" +If this environment variable is defined (with any value), +show the auxiliary array passed up from the kernel (see also +.BR getauxval (3)). +.IP +Since glibc 2.3.4, +.B LD_SHOW_AUXV +is ignored in secure-execution mode. +.TP +.BR LD_TRACE_PRELINKING " (from glibc 2.4 to glibc 2.35)" +If this environment variable is defined, +trace prelinking of the object whose name is assigned to +this environment variable. +(Use +.BR ldd (1) +to get a list of the objects that might be traced.) +If the object name is not recognized, +.\" (This is what seems to happen, from experimenting) +then all prelinking activity is traced. +.TP +.BR LD_USE_LOAD_BIAS " (from glibc 2.3.3 to glibc 2.35)" +.\" http://sources.redhat.com/ml/libc-hacker/2003-11/msg00127.html +.\" Subject: [PATCH] Support LD_USE_LOAD_BIAS +.\" Jakub Jelinek +By default (i.e., if this variable is not defined), +executables and prelinked +shared objects will honor base addresses of their dependent shared objects +and (nonprelinked) position-independent executables (PIEs) +and other shared objects will not honor them. +If +.B LD_USE_LOAD_BIAS +is defined with the value 1, both executables and PIEs +will honor the base addresses. +If +.B LD_USE_LOAD_BIAS +is defined with the value 0, +neither executables nor PIEs will honor the base addresses. +.IP +Since glibc 2.3.3, this variable is ignored in secure-execution mode. +.TP +.BR LD_VERBOSE " (since glibc 2.1)" +If set to a nonempty string, +output symbol versioning information about the +program if the +.B LD_TRACE_LOADED_OBJECTS +environment variable has been set. +.TP +.BR LD_WARN " (since glibc 2.1.3)" +If set to a nonempty string, warn about unresolved symbols. +.TP +.BR LD_PREFER_MAP_32BIT_EXEC " (x86-64 only; since glibc 2.23)" +According to the Intel Silvermont software optimization guide, for 64-bit +applications, branch prediction performance can be negatively impacted +when the target of a branch is more than 4\ GB away from the branch. +If this environment variable is set (to any value), +the dynamic linker +will first try to map executable pages using the +.BR mmap (2) +.B MAP_32BIT +flag, and fall back to mapping without that flag if that attempt fails. +NB: MAP_32BIT will map to the low 2\ GB (not 4\ GB) of the address space. +.IP +Because +.B MAP_32BIT +reduces the address range available for address space layout +randomization (ASLR), +.B LD_PREFER_MAP_32BIT_EXEC +is always disabled in secure-execution mode. +.SH FILES +.TP +.I /lib/ld.so +a.out dynamic linker/loader +.TP +.IR /lib/ld\-linux.so. { 1 , 2 } +ELF dynamic linker/loader +.TP +.I /etc/ld.so.cache +File containing a compiled list of directories in which to search for +shared objects and an ordered list of candidate shared objects. +See +.BR ldconfig (8). +.TP +.I /etc/ld.so.preload +File containing a whitespace-separated list of ELF shared objects to +be loaded before the program. +See the discussion of +.B LD_PRELOAD +above. +If both +.B LD_PRELOAD +and +.I /etc/ld.so.preload +are employed, the libraries specified by +.B LD_PRELOAD +are preloaded first. +.I /etc/ld.so.preload +has a system-wide effect, +causing the specified libraries to be preloaded for +all programs that are executed on the system. +(This is usually undesirable, +and is typically employed only as an emergency remedy, for example, +as a temporary workaround to a library misconfiguration issue.) +.TP +.I lib*.so* +shared objects +.SH NOTES +.SS Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37) +Some shared objects are compiled using hardware-specific instructions which do +not exist on every CPU. +Such objects should be installed in directories whose names define the +required hardware capabilities, such as +.IR /usr/lib/sse2/ . +The dynamic linker checks these directories against the hardware of the +machine and selects the most suitable version of a given shared object. +Hardware capability directories can be cascaded to combine CPU features. +The list of supported hardware capability names depends on the CPU. +The following names are currently recognized: +.\" Presumably, this info comes from sysdeps/i386/dl-procinfo.c and +.\" similar files +.TP +.B Alpha +ev4, ev5, ev56, ev6, ev67 +.TP +.B MIPS +loongson2e, loongson2f, octeon, octeon2 +.TP +.B 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 +.TP +.B SPARC +flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2 +.TP +.B s390 +dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, +z900, z990, z9-109, z10, zarch +.TP +.B x86 (32-bit only) +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 +.P +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. +.P +For instance, on x86 32-bit, +if the hardware supports +.B i686 +and +.BR sse2 , +the resulting search path will be +.BR i686/sse2:i686:sse2:. . +A new capability +.B newcap +will set the search path to +.BR newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2: . +.\" +.SS glibc Hardware capabilities (from glibc 2.33) +.TP +.\" The initial discussion on various pitfalls of the old scheme is +.\" <https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html> +.\" and the patchset that proposes the glibc-hwcap support is +.\" <https://sourceware.org/pipermail/libc-alpha/2020-June/115250.html> +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. +.P +For instance, on x86 64-bit, +if the hardware supports +.B x86_64-v3 +(for instance Intel Haswell or AMD Excavator), +the resulting search path will be +.B glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. +.\" The x86_64 architectures levels are defined the official ABI: +.\" <https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex> +.\" The PowerPC and s390x are glibc defined ones based on chip +.\" support (which maps to ISA levels). +The following paths are currently supported, in priority order. +.TP +.B PowerPC (64-bit little-endian only) +power10, power9 +.TP +.B s390 (64-bit only) +z16, z15, z14, z13 +.TP +.B x86 (64-bit only) +x86-64-v4, x86-64-v3, x86-64-v2 +.P +glibc 2.37 removed support for the legacy hardware capabilities. +.\" +.SH SEE ALSO +.BR ld (1), +.BR ldd (1), +.BR pldd (1), +.BR sprof (1), +.BR dlopen (3), +.BR getauxval (3), +.BR elf (5), +.BR capabilities (7), +.BR rtld\-audit (7), +.BR ldconfig (8), +.BR sln (8) +.\" .SH AUTHORS +.\" ld.so: David Engel, Eric Youngdale, Peter MacDonald, Hongjiu Lu, Linus +.\" Torvalds, Lars Wirzenius and Mitch D'Souza +.\" ld\-linux.so: Roland McGrath, Ulrich Drepper and others. +.\" +.\" In the above, (libc5) stands for David Engel's ld.so/ld\-linux.so. |