diff options
Diffstat (limited to 'man8/ld.so.8')
| -rw-r--r-- | man8/ld.so.8 | 127 |
1 files changed, 107 insertions, 20 deletions
diff --git a/man8/ld.so.8 b/man8/ld.so.8 index afd29c5..8767b50 100644 --- a/man8/ld.so.8 +++ b/man8/ld.so.8 @@ -4,7 +4,7 @@ .\" Various parts: .\" Copyright (C) 2007-9, 2013, 2016 Michael Kerrisk <mtk.manpages@gmail.com> .\" -.TH ld.so 8 2023-07-18 "Linux man-pages 6.05.01" +.TH ld.so 8 2024-02-12 "Linux man-pages 6.7" .SH NAME ld.so, ld\-linux.so \- dynamic linker/loader .SH SYNOPSIS @@ -15,7 +15,7 @@ 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: -.PP +.P .I /lib/ld\-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]] .SH DESCRIPTION @@ -25,14 +25,14 @@ 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. -.PP +.P Linux binaries require dynamic linking (linking at run time) unless the .B \-static option was given to .BR ld (1) during compilation. -.PP +.P The program .B ld.so handles a.out binaries, a binary format used long ago. @@ -46,7 +46,7 @@ support files and programs .BR ldconfig (8), and .IR /etc/ld.so.conf ). -.PP +.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 @@ -54,7 +54,7 @@ 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. -.PP +.P If a shared object dependency does not contain a slash, then it is searched for in the following order: .IP (1) 5 @@ -132,7 +132,7 @@ in the filename arguments to the and .BR dlmopen (3) functions. -.PP +.P The substituted tokens are as follows: .TP .IR $ORIGIN " (or equivalently " ${ORIGIN} ) @@ -187,7 +187,7 @@ value in the auxiliary vector (see .\" .\" ld.so lets names be abbreviated, so $O will work for $ORIGIN; .\" Don't do this!! -.PP +.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. @@ -208,6 +208,14 @@ 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 . @@ -238,6 +246,16 @@ are delimited by colons or spaces. .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. @@ -280,6 +298,17 @@ Other environment variables treated in this way include: .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 , @@ -289,7 +318,7 @@ Other environment variables treated in this way include: .BR TMPDIR , and .BR TZDIR . -.PP +.P A binary is executed in secure-execution mode if the .B AT_SECURE entry in the auxiliary vector (see @@ -310,7 +339,7 @@ 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 " (since glibc 2.2.3)" +.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 @@ -457,7 +486,7 @@ If set (to any value), causes the program to list its dynamic dependencies, as if run by .BR ldd (1), instead of running normally. -.PP +.P Then there are lots of more or less obscure variables, many obsolete or only for internal use. .TP @@ -627,8 +656,11 @@ Since glibc 2.3.4, .B LD_DYNAMIC_WEAK is ignored in secure-execution mode. .TP -.BR LD_HWCAP_MASK " (since glibc 2.1)" +.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. @@ -663,7 +695,7 @@ Profiling output is appended to the file whose name is: .IP Since glibc 2.2.5, .B LD_PROFILE -is ignored in secure-execution mode. +uses a different default path in secure-execution mode. .TP .BR LD_PROFILE_OUTPUT " (since glibc 2.1)" Directory where @@ -677,10 +709,6 @@ then the default is is ignored in secure-execution mode; instead .I /var/profile is always used. -(This detail is relevant only before glibc 2.2.5, -since in later glibc versions, -.B LD_PROFILE -is also ignored in secure-execution mode.) .TP .BR LD_SHOW_AUXV " (since glibc 2.1)" If this environment variable is defined (with any value), @@ -691,7 +719,7 @@ Since glibc 2.3.4, .B LD_SHOW_AUXV is ignored in secure-execution mode. .TP -.BR LD_TRACE_PRELINKING " (since glibc 2.4)" +.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. @@ -702,7 +730,7 @@ 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 " (since glibc 2.3.3)" +.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 @@ -788,7 +816,7 @@ as a temporary workaround to a library misconfiguration issue.) .I lib*.so* shared objects .SH NOTES -.SS Hardware capabilities +.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 @@ -823,6 +851,65 @@ z900, z990, z9-109, z10, zarch .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), |