diff options
Diffstat (limited to 'man8/ld.so.8')
| -rw-r--r-- | man8/ld.so.8 | 930 |
1 files changed, 0 insertions, 930 deletions
diff --git a/man8/ld.so.8 b/man8/ld.so.8 deleted file mode 100644 index 8767b50..0000000 --- a/man8/ld.so.8 +++ /dev/null @@ -1,930 +0,0 @@ -.\" %%%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 2024-02-12 "Linux man-pages 6.7" -.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. |