ldd: Usage, Options & Common CI Errors
ldd shows which shared libraries an executable depends on, and whether they resolve.
ldd is the diagnostic for the dreaded "error while loading shared libraries" failure. It reveals missing .so files and the glibc-vs-musl mismatch that breaks binaries copied between Alpine and Debian images.
What it does
ldd prints the shared library dependencies of a program or library and the path each resolves to (or "not found"). It is how you learn why a dynamically linked binary refuses to run.
Common usage
ldd ./myapp
ldd ./myapp | grep 'not found' # show only missing deps
ldd $(which node)
ldd ./binary 2>&1 || true # capture musl's error tooOptions
| Item | What it does |
|---|---|
| ldd <file> | List shared library dependencies |
| grep "not found" | Isolate unresolved libraries |
| -v / --verbose | Show versioning details (glibc) |
| -u / --unused | List unused direct dependencies |
Common errors in CI
A line ending in "=> not found" means a required .so is missing - install the providing package (e.g. libssl, libstdc++) or set LD_LIBRARY_PATH. "not a dynamic executable" means the file is statically linked (or not an ELF for this arch). The big CI trap: a glibc binary built on Debian fails on Alpine with "Error loading shared library ... No such file or directory" because Alpine uses musl - ldd on Alpine is a busybox stub and even reports differently. Match the build and runtime libc.