Using the "ldd" Command in Linux

Use the ldd command to show the shared libraries required by any given program — useful for working out when there is a missing dependency. The command also lists missing functions and objects.

ldd Command Syntax

Observe the proper syntax for the ldd command to avoid errors:

ldd [OPTION]... FILE...

Use one or more of the available ldd command switches, inserted into the [OPTION] spot in the above command:

 --help | print this help and exit
 --version | print version information and exit
 -d, --data-relocs | process data relocations
 -r, --function-relocs | process data and function relocations
 -u, --unused | print unused direct dependencies
 -v, --verbose | print all information

How to Use the ldd Command

Execute the following command to get more information about a program:

$ldd -v /path/to/program/executable

The output shows version information as well as the paths and addresses to the shared libraries, like this:

$ldd libshared.so
linux-vdso.so.1 => (0x00007fff26ac8000)
libc.so.6 => /lib/libc.so.6 0x00007ff1df55a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1dfafe000)

If the SO file doesn't exist at all, you can find the missing libraries using the following command:

$ldd -d path/to/program

The output is similar to the following:

linux-vdso.so.1 (0x00007ffc2936b000)
/home/gary/demo/garylib.so => not foundlibc.so.6 => usr/lib/libc.so.6 (0x00007fd0c6259000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd0c65fd000)

Never run the ldd command against an untrusted program because the ldd might actually execute it. Instead, use a safer alternative that shows just the direct dependencies and not the whole dependency tree:

$objdump -p /path/to/program | grep NEEDED

How to Find the Path to an Application

You have to provide the full path to an application if you want to find its dependencies with ldd, which you can do in several ways.

For example, this is how you'd find the path to Firefox:

$find / -name firefox

The problem with the find command, however, is that it will not only list the executable but everywhere that Firefox is located, like this:

• /etc/skel/.mozilla/firefox
• /home//cache/mozilla/firefox
• /home//.mozilla/firefox
• /usr/bin/Firefox
• /usr/lib/Firefox
• /usr/lib/Firefox/Firefox

This approach is a bit of an overkill and you may need to use the sudo command to elevate your privileges, else you're likely to get lots of permission-denied errors.

It's instead much easier to use the whereis command to find an application's path:

$whereis firefox

This time the output might look like this:

/usr/bin/firefox

/etc/firefox

/usr/lib/firefox

All you have to do now to find the shared libraries for Firefox is type the following command:

$ldd /usr/bin/firefox

The output from the command will be something like this:

linux-vdso.so.1 (0x00007ffff8364000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007feb9917a000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007feb98f76000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007feb98bf4000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007feb988f6000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007feb986e0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007feb9833c000)
/lib64/ld-linux-x86-64.so.2 (0x00007feb99397000)

Linux-vdso.so.1 is the name of the library and the hex number is the address where the library will be loaded to in memory.

You'll notice on many of the other lines that the => symbol is followed by a path. This is the path to the physical binary; the hex number is the address where the library will be loaded