Ldconfig vs Ldd Command
ldconfig builds the shared-library cache so the dynamic linker can find your .so files; ldd shows what a binary links against. They are bookends on the same pipeline, so the winner is the one you actually reach for to fix things — and that's ldconfig.
The short answer
Ldconfig over Ldd Command for most cases. ldconfig fixes problems; ldd only describes them.
- Pick Ldconfig if installing libraries to non-standard paths, packaging software, or fixing 'cannot open shared object file' errors — ldconfig rebuilds /etc/ld.so.cache so the loader actually finds them
- Pick Ldd Command if only need to inspect a binary's declared dynamic dependencies and confirm each one resolves, without changing anything on disk
- Also consider: patchelf when you need to rewrite an existing binary's rpath or interpreter, and objdump -p / readelf -d for the safe, non-executing way to read dependencies on untrusted binaries.
— Nice Pick, opinionated tool recommendations
What they actually do
ldconfig and ldd are not competitors so much as bookends around dynamic linking. ldconfig scans the directories in /etc/ld.so.conf (and /etc/ld.so.conf.d/*.conf) plus the trusted defaults /lib and /usr/lib, then writes /etc/ld.so.cache — the lookup table the loader consults at every program start. It is a write operation; it changes system state. ldd does the opposite: hand it a binary and it reports each shared object that binary requests and the path the loader would resolve it to. It changes nothing. You run ldconfig after dropping new libraries somewhere the cache does not know about. You run ldd when a program will not start and you want to see which dependency is missing. Same problem, opposite ends. Treating them as rivals is a category error people make because they appear in the same Stack Overflow answer. They cooperate; they do not compete.
Where ldd will bite you
ldd has a dirty secret: on many systems it works by setting LD_TRACE_LOADED_OBJECTS and effectively running the loader against your binary. Point it at an untrusted executable and you can be tricked into executing attacker-controlled code via a malicious interpreter line. The man page itself warns against running ldd on programs you do not trust. That alone disqualifies it as your default inspection tool — use objdump -p or readelf -d, which parse the ELF without running anything. ldd also lies by omission: it shows what the loader would pick today, which can differ from what runs after an LD_LIBRARY_PATH change or an ldconfig refresh. It is a snapshot, not a contract. Useful for a quick 'is libfoo.so.2 resolving?' glance, genuinely dangerous as a habit. Convenient and a little reckless — the worst combination in a security context.
Where ldconfig earns its keep
ldconfig is the unglamorous tool that makes everything else work. Install a library to /opt/something/lib and your binary still cannot find it until ldconfig knows that path exists — add it under /etc/ld.so.conf.d/, run ldconfig, done. It also creates the versioned symlinks (libfoo.so.2 -> libfoo.so.2.3.1) that the SONAME mechanism depends on, which is why a half-built library tree with missing symlinks magically heals after one ldconfig run. Run ldconfig -p to dump the cache and you get the authoritative answer to 'what does this system actually see,' which is more trustworthy than ldd's per-binary guess. The catch: it writes to /etc/, so it needs root, and forgetting to run it after a manual install is the single most common cause of the 'cannot open shared object file' error people then blame on ldd for not fixing.
The verdict, plainly
If you forced me to keep exactly one on a fresh box, I keep ldconfig. ldd's job — reading dependencies — is done more safely by readelf -d and objdump -p, both of which ship with the same toolchains and never execute the target. ldconfig's job has no safe substitute you would actually type; rebuilding the loader cache and the SONAME symlinks is its alone. The pattern is simple: ldconfig changes reality, ldd merely comments on it, and changing reality is what you are paid for. Keep ldd around for the ten-second sanity check when a binary will not launch, but understand it is the diagnostic, not the treatment. Reach for ldconfig when something is broken and you want it fixed. Reach for ldd when you want to nod at the problem before fixing it the real way. The fixer wins.
Quick Comparison
| Factor | Ldconfig | Ldd Command |
|---|---|---|
| Primary action | Writes /etc/ld.so.cache — changes system state to make libraries findable | Reads a binary and reports its resolved dynamic dependencies |
| Safety on untrusted input | Safe; operates on cache and config directories | Can execute attacker-controlled code via the loader; man page warns against it |
| Fixes the error vs. describes it | Resolves 'cannot open shared object file' by registering paths and symlinks | Only shows which dependency is missing |
| Privilege required | Needs root to write /etc/ld.so.cache | Runs as any user, read-only |
| Replaceability | No safe everyday substitute for cache + SONAME symlink rebuild | readelf -d / objdump -p do the same inspection without executing |
The Verdict
Use Ldconfig if: You're installing libraries to non-standard paths, packaging software, or fixing 'cannot open shared object file' errors — ldconfig rebuilds /etc/ld.so.cache so the loader actually finds them.
Use Ldd Command if: You only need to inspect a binary's declared dynamic dependencies and confirm each one resolves, without changing anything on disk.
Consider: patchelf when you need to rewrite an existing binary's rpath or interpreter, and objdump -p / readelf -d for the safe, non-executing way to read dependencies on untrusted binaries.
Ldconfig vs Ldd Command: FAQ
Is Ldconfig or Ldd Command better?
Ldconfig is the Nice Pick. ldconfig fixes problems; ldd only describes them. When a binary screams "cannot open shared object file," ldd tells you the obvious. ldconfig — after dropping a .conf in /etc/ld.so.conf.d/ — is what makes the error vanish. One is a doctor, the other a thermometer. The thermometer is useful, but you don't thank it for the cure.
When should you use Ldconfig?
You're installing libraries to non-standard paths, packaging software, or fixing 'cannot open shared object file' errors — ldconfig rebuilds /etc/ld.so.cache so the loader actually finds them.
When should you use Ldd Command?
You only need to inspect a binary's declared dynamic dependencies and confirm each one resolves, without changing anything on disk.
What's the main difference between Ldconfig and Ldd Command?
ldconfig builds the shared-library cache so the dynamic linker can find your .so files; ldd shows what a binary links against. They are bookends on the same pipeline, so the winner is the one you actually reach for to fix things — and that's ldconfig.
How do Ldconfig and Ldd Command compare on primary action?
Ldconfig: Writes /etc/ld.so.cache — changes system state to make libraries findable. Ldd Command: Reads a binary and reports its resolved dynamic dependencies. Ldconfig wins here.
Are there alternatives to consider beyond Ldconfig and Ldd Command?
patchelf when you need to rewrite an existing binary's rpath or interpreter, and objdump -p / readelf -d for the safe, non-executing way to read dependencies on untrusted binaries.
ldconfig fixes problems; ldd only describes them. When a binary screams "cannot open shared object file," ldd tells you the obvious. ldconfig — after dropping a .conf in /etc/ld.so.conf.d/ — is what makes the error vanish. One is a doctor, the other a thermometer. The thermometer is useful, but you don't thank it for the cure.
Related Comparisons
Disagree? nice@nicepick.dev