summaryrefslogtreecommitdiffstats
path: root/man8/ld.so.8
diff options
context:
space:
mode:
Diffstat (limited to 'man8/ld.so.8')
-rw-r--r--man8/ld.so.8127
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),