Using the ldd command in Linux

Shared object files streamline programs by providing the information that applications need to do their job, but don’t have to be part of the application itself. To find out which of these files a Linux command is calling on, use the command ldd order.

What is a shared object file?

Shared object files (denoted by .so) are libraries that are automatically linked to a program when the program starts, but exist as standalone files. They contain information that can be used by one or more programs to offload resources so that any program calling a .so file does not have to provide all the necessary tools itself. These files can be linked to any program and loaded anywhere into memory.

A single .so file can contain information and functions for quickly searching the entire computer or performing very complex calculations. Several programs can then call on this .so file. In fact, .so files can be updated/replaced without these programs having to modify their own code.

Shared libraries can be linked to any program at runtime. Think of them as pieces of code that can be used by many different programs, thus allowing those programs to be smaller and much more efficient than ensuring that all programs that use them contain them and are updated if necessary if the code changes.

Using ldd

This simple example uses ldd to find out which files Dated command uses:

$ ldd /usr/bin/date (0x00007ffd230e5000) => /lib64/ (0x00007f8e9fc54000)
        /lib64/ (0x00007f8e9fe52000)

The above result shows that the Dated The command uses three shared object files.

Note that you must include a full file path when using ldd. Otherwise, ldd searches the current directory for the name of the program and probably won’t find it.

$ ldd date
ldd: ./date: No such file or directory

If you are unsure of the location of a particular program, you can use the which order in one of the forms below.

$ which pwd
$ ldd /usr/bin/pwd (0x00007ffe9df9b000) => /lib64/ (0x00007f686d670000)
        /lib64/ (0x00007f686d85d000)


$ ldd `which pwd` (0x00007ffc3b9e4000) => /lib64/ (0x00007f2d491a9000)
        /lib64/ (0x00007f2d49396000)

You can get much more information using the -v (Where –verbose) options:

$ ldd -v `which pwd` (0x00007ffeea1f6000) => /lib64/ (0x00007ff3b0c64000)
        /lib64/ (0x00007ff3b0e51000)

        Version information:
       (GLIBC_2.3) => /lib64/
       (GLIBC_2.14) => /lib64/
       (GLIBC_2.3.4) => /lib64/
       (GLIBC_2.33) => /lib64/
       (GLIBC_2.4) => /lib64/
       (GLIBC_2.2.5) => /lib64/
       (GLIBC_2.2.5) => /lib64/
       (GLIBC_2.3) => /lib64/
       (GLIBC_PRIVATE) => /lib64/

the ldd The command is sometimes used when it seems that a needed shared library is missing, and instead a “not found” message is generated. For example:

          => not found

If several or all of the necessary libraries are missing, you may be missing a configuration file or a symbolic link to establish the connection. Missing shared object files are very rare and you are unlikely to encounter this problem.

Some programs use only a few shared libraries while others use a stack. Take a look at the to restart command and you will see a very long list of files like this:

$ ldd /usr/sbin/reboot (0x00007ffd0b374000) => /usr/lib/systemd/ (0x00007f30fbec3000) => /lib64/ (0x00007f30fbe9a000) => /lib64/ (0x00007f30fbc90000) => /lib64/ (0x00007f30fbc85000) => /lib64/ (0x00007f30fbc4d000) => /lib64/ (0x00007f30fbc43000) => /lib64/ (0x00007f30fbc07000) => /lib64/ (0x00007f30fbacb000) => /lib64/ (0x00007f30fbac1000) => /lib64/ (0x00007f30fbaa6000) => /lib64/ (0x00007f30fba82000) => /lib64/ (0x00007f30fba3d000) => /lib64/ (0x00007f30fb74d000) => /lib64/ (0x00007f30fb61b000) => /lib64/ (0x00007f30fb609000) => /lib64/ (0x00007f30fb5e8000) => /lib64/ (0x00007f30fb5bc000) => /lib64/ (0x00007f30fb4c6000) => /lib64/ (0x00007f30fb498000)
        /lib64/ (0x00007f30fc216000) => /lib64/ (0x00007f30fb490000) => /lib64/ (0x00007f30fb46a000) => /lib64/ (0x00007f30fb41d000) => /lib64/ (0x00007f30fb403000) => /lib64/ (0x00007f30fb3f6000) => /lib64/ (0x00007f30fb3c8000) => /lib64/ (0x00007f30fb3bd000) => /lib64/ (0x00007f30fb2e1000) => /lib64/ (0x00007f30fb24a000) => /lib64/ (0x00007f30fb228000) => /lib64/ (0x00007f30fb21d000) => /lib64/ (0x00007f30fb197000) => /lib64/ (0x00007f30fb173000)

Of course, what this output doesn’t tell you is how many programs are using these shared libraries and how much trouble you would have if one of the most important ones were removed from your system. Even common commands can stop working.

Don’t be fooled. It’s likely that every command you enter on a Linux system uses shared libraries. Even a command as modest as echo uses several:

$ ldd /usr/bin/echo (0x00007ffdbf99d000) => /lib64/ (0x00007f0696277000)
        /lib64/ (0x00007f069649c000)

The criticality of these files is quite obvious. Luckily, it’s easy to like them, but if not, let them do their thing. There is no way to watch them or find out how they work. You can view some details like the ones shown below, but that doesn’t give much information about the functions provided by the files.

$ ls -l /lib64/
-rwxr-xr-x. 1 root root 2387984 Oct  1 14:19 /lib64/
$ file /lib64/
/lib64/ ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
dynamically linked, interpreter lib64/, BuildID[sha1]=
f891252f9069edee265f92cfb9a163880999588b, for GNU/Linux 3.2.0, not stripped


Shared object files are an extremely important part of any Linux system because they allow programs to share resources that can be updated and loaded into memory separately. It’s easy to determine which shared object files a particular command uses, but nearly impossible to determine what roles they play.

Join the Network World communities on Facebook and LinkedIn to comment on topics that matter to you.

Copyright © 2022 IDG Communications, Inc.

Comments are closed.