+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 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