Every Linux developer who's wasted an afternoon hunting down a wrong-library-load bug should know that LD_DEBUG cuts that to seconds. B. Nikolic's blog post from 2012 (updated through 2023) nails the workflow: one environment variable turns the dynamic linker into a verbose forensic log.
What LD_DEBUG Exposes That strace Misses
strace shows system calls — including open() calls for .so files — but it buries the linker's decision logic in a wall of noise. LD_DEBUG prints the linker's internal search path, cache lookups, and symbol binding in human-readable form. Run LD_DEBUG=help cat to see options: libs for library paths, symbols for symbol table processing, bindings for which symbol gets resolved to what. Combine them with all.
Nikolic's example output for LD_DEBUG=all cat shows the linker stepping through every search directory, hitting the cache at /etc/ld.so.cache, and finally loading /lib/x86_64-linux-gnu/libc.so.6. You see each trying file= line, the exact version checks (GLIBC_2.4, GLIBC_2.3), and the relocation processing. No guesswork.
The One-Liner That Resolves Most Library Conflicts
LD_DEBUG=libs myprogram prints the full search path resolution. If you need to capture output to a file, set LD_DEBUG_OUTPUT=/tmp/debug.log. That's it. Compare to the alternative: strace -e openat myprogram 2>&1 | grep \.so — still less readable and you miss why the linker chose one path over another.
Nikolic also points to companion tools: ldd for dependency listing, objdump -x YOURFILE | grep NEEDED for explicit required libraries, and patchelf to rewrite RPATH. But LD_DEBUG is the first responder.
The next time a segfault or cryptic "cannot open shared object" hits, don't reach for gdb first. Export LD_DEBUG=libs, run the binary, and watch the linker confess exactly which .so it loaded and where it searched.
Source: The LD_DEBUG environment variable (2012)
Domain: bnikolic.co.uk
Comments load interactively on the live page.