How to Troubleshoot Linux Binaries with ldd Command

The ldd (List Dynamic Dependencies) command is a critical diagnostic utility in Linux used to inspect the shared libraries required by an executable at runtime. This guide explains the core purpose of ldd, how to interpret its output, common binary execution errors it helps resolve, and safe practices for analyzing dynamic dependencies during system troubleshooting.

What is the Purpose of ldd?

Most Linux programs are dynamically linked, meaning they do not bundle all their required code into a single executable file. Instead, they rely on shared objects (files ending in .so) provided by the operating system. When an application launches, the Linux dynamic linker (ld.so or ld-linux.so) must locate and load these libraries into memory.

The ldd command simulates this loading process to display every shared library the binary depends on, where those libraries are located on the filesystem, and the memory address where they would be loaded.

Primary Troubleshooting Use Cases

1. Resolving "No such file or directory" and Missing Library Errors

The most common scenario for running ldd is encountering runtime loader errors, such as:

error while loading shared libraries: libexample.so.1: cannot open shared object file: No such file or directory

Running ldd against the problematic binary immediately pinpoints which library is absent:

ldd /usr/bin/my_application

Output example:

linux-vdso.so.1 (0x00007ffe315ce000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f59d5a00000)
libexample.so.1 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f59d5800000)
/lib64/ld-linux-x86-64.so.2 (0x00007f59d5b53000)

The line containing not found reveals the exact missing dependency that prevents the binary from running.

2. Identifying Library Version Mismatches

When multiple versions of a shared library exist on a system (for example, in /usr/lib and /usr/local/lib), a binary may link to an unexpected version, leading to undefined symbol errors or segmentation faults. ldd reveals the absolute path to each resolved file, allowing administrators to confirm whether the binary binds to the intended library build.

3. Verifying Search Path Configurations

Linux searches for libraries using hardcoded runpaths (RPATH/RUNPATH), system directories (/etc/ld.so.conf and /etc/ld.so.cache), and the LD_LIBRARY_PATH environment variable. Running ldd helps verify whether changes to LD_LIBRARY_PATH or custom library directories successfully resolve runtime paths for a specific program.

4. Checking Static vs. Dynamic Linking

If there is uncertainty about whether an executable was built as a standalone static binary or requires dynamic dependencies, ldd provides immediate confirmation:

ldd /sbin/sln

Output:

not a dynamic executable

Security Consideration

The ldd command works by invoking the dynamic linker with specific environment variables, which can lead to the execution of code contained within the target binary in certain environments. To inspect untrusted or potentially malicious binaries safely, use alternative tools such as objdump -p <binary> or readelf -d <binary>, which parse binary headers statically without invoking the dynamic loader.