What it does
ldd prints the shared libraries required by a program and where the dynamic linker will load them from. It answers the question: “what does this binary depend on at runtime?”
How it works (mechanical)
ldd uses the system’s dynamic loader to resolve dependencies
declared in the ELF dynamic section. In many implementations, it does this
by invoking the loader in a controlled inspection mode.
- Reads ELF
NEEDEDentries - Resolves libraries using loader search paths
- Shows actual resolved file locations
- Reflects runtime linker configuration
10 Practical Examples
# 1) Show library dependencies ldd /bin/ls
# 2) Diagnose missing libraries ldd mybinary
# 3) Check which libc is used ldd mybinary | grep libc
# 4) Identify unexpected dependencies ldd mybinary | sort
# 5) Debug "not found" errors ldd mybinary | grep not
# 6) Compare dependencies between systems ldd mybinary > deps.txt
# 7) Inspect shared library dependencies ldd /lib/x86_64-linux-gnu/libssl.so.3
# 8) Verify container runtime libraries ldd /usr/bin/myapp
# 9) Show dynamic loader itself ldd /lib64/ld-linux-x86-64.so.2
# 10) Pre-flight binary portability
ldd mybinary | awk '{print $1}'Notes & Gotchas
- Never run
lddon untrusted binaries. - Some implementations execute the binary under the loader.
- Static binaries will report “not a dynamic executable”.
- Results depend on
LD_LIBRARY_PATHand loader config. - For safer inspection, prefer
readelf -d.
Historical Context
ldd emerged alongside dynamic linking to help developers
diagnose runtime failures due to missing or mismatched libraries.
It remains a first-stop tool for “works here, fails there” problems.
Modern Equivalent / Related Tools
- readelf -d — inspect NEEDED entries safely
- ldconfig -p — view linker cache
- patchelf — modify runtime dependencies
- strace — observe library loading live
- objdump -p — program header inspection