how to use ldd?

Shared object files (designated as .so) are libraries that are automatically linked into a program when the program starts, yet exist as a 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 doesn't itself have to actually provide all the needed tools. These files can be linked to any program and be loaded anywhere in memory.

A single .so file might contain information and functions on how to quickly search through the whole computer or perform very complex calculations. Several programs can then call upon that .so file. In fact, .so files can be updated/replaced without those programs having to make any changes to their own code.

Shared libraries can be linked to any program at run-time. Think of them as chunks of code that can be used by many different programs, thus allowing those programs to be smaller and much more efficient than ensuring all the programs that use them contain them and get updated as needed if the code changes.

This simple example uses ldd to find out what files the date command uses:

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

Note that you have to include a full pathname to the file when using ldd. Otherwise, ldd looks into the current directory for the program name and isn't likely to find it.

If you're not sure where a particular program is located, you can use the which command in either of the forms shown below.

or

You can get a lot more information by using the -v (or --verbose) option:

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

If many or all of the needed libraries are missing, you might actually be missing a configuration file or symbolic link meant to make the connection. Missing shared object files are very uncommon, and you are unlikely to ever run into this problem.

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

Of course, what this output doesn't tell you is how many programs use these shared libraries and how much trouble you would have if one of the more important ones was removed from your system. Even common commands could stop working.

Don't be fooled. Likely every command that you enter on a Linux system is using shared libraries. Even as modest a command as echo uses several:

The criticality of these files is quite obvious. Fortunately, it's easy to appreciate them, but otherwise let them do their thing. There's no way to peer into them or inquire about how they work. You can display some details like those shown below, but this doesn't provide much insight the functions the files provide.

Q1. How to use the ldd command? Basic usage of ldd is fairly simple - just run the 'ldd' command along with an executable or shared object file name as input. So you can see all shared library dependencies have been produced in output.

If you’re using a Linux machine, you will be dealing with executable files constantly – be it on the GUI or on your terminal. Executables are comprised of shared libraries, and these are used and reused across programs.

Windows users might recognize that the DDL files on their machine are shared libraries. However, these files are stored on Linux with the .o and .so extensions.

In this brief guide, we discuss how you can use the ldd utility on the Linux command line to view an executable’s shared objects and dependencies. But first, let’s understand what a shared object file is.

As you might be able to guess, a .so extension file denotes a shared object file. These files hold libraries that link to their associated program automatically when they run. However, these aren’t a part of the program’s executables and exist as standalone files.

These can be loaded anywhere in memory. More interestingly, .so files hold information that more than a single program can use to offload resources. In other words, any program calling a shared object file doesn’t have to provide it with all the necessary tools.

One .so file might hold functions that instruct the computer to search through all its files and also hold functions that perform complex calculations. Many programs can call this same .so file and use the functions they require.

What’s more, .so files can be updated or replaced without the programs that use them requiring changes in their code. You can think of a shared object file as chunks of code that various programs can use. These files optimize the size of programs, which also ensures their efficiency.

The ldd command has a single objective – printing the shared libraries that a program requires. You can also make it print the shared library you specify on the command line.

We’ve discussed shared object files but not libraries. A library is a collection of pre-compiled resources, such as classes, values, subroutines, and functions. All of these resources are used to create a library.

Libraries are of two kinds: static and dynamic. Linux typically stores library files in the /lib or /usr/lib directories.

Virtually all Linux distributions come with the ldd command installed by default. However, if it’s not available on your machine, run the following command:

It’ll take a few seconds to install.

The best thing about using ldd is that its syntax is straightforward:

Running the command displays the shared object dependencies by default. Let’s say you want to view the dependencies of the bash binary shared library. To do this, you could run the command:

The first part of the output will show you the virtual dynamic shared object. In the second line, you will see the ELF interpreter’s path that’s hardcoded into the executable. In the final section, you will find the details of the memory where the library is loaded.

When the ldd command is used, it typically invokes the standard dynamic linker. The LD_TRACE_LOADED_OBJECTS environment variable is set to 1, causing the linker to display the dependencies, accomplishing what ldd is supposed to do.

However, in some versions of the command and some circumstances, ldd might resort to obtaining the information by executing the program directly. For this reason, it’s extremely unsafe to run ldd on an executable you do not trust.

There’s a chance that the program might run some arbitrary code that could lead to a breach in your machine.

If you don’t have any other choice but to run an untrusted executable, it’s a lot safer to run the following:

Like in any other command, using options with ldd modifies its behavior. To use ldd to generate additional information about the dependencies, such as the symbol versioning data, you can use the -v option.

On the other hand, you can use the -u option to make the command generate direct dependencies.

The ldd command supports two more options: the -d and -r options. Both commands perform data relocations; however, the latter can relocate both objects and functions. If there are any missing ELF objects, both commands will report them to you.

• Display dependencies of the command.
• Display dependencies of the command with details.
• Display unused direct dependencies of the command.
• Display ldd works only on dynamic executables.
• ldd with standard command line executable.
• Know a given executable daemon supports TCP Wrapper.

A library makes it possible for a program to use common routines without the administrative overhead of maintaining their source code, or the processing overhead of compiling them each time the program is compiled.

There are two types of libraries:

Static libraries: static libraries for complete programs that do not depend on external libraries to run. The feature of statically linked programs is that they work without installing any prerequisites. The static library is end with *.a extension and these libraries are included (a separate copy) into the programs that require its functions.

Dynamic libraries: dynamic libraries for tiny programs in size, These libraries end with .so extension, Another feature of using dynamic linking when many programs are running, It can share one copy of a library rather than occupying memory with many copies of the same code. So the recent programs use dynamic linking. In this article, we will go through the commands ldd which is used to manage the shared libraries.

When we make a program, we need many pieces of code that someone else has already written to perform routine or specialized functions for us. These pieces of code are stored in shared libraries. To use them, we link them with our code, either when we build the program or when we run the program.

The ldd command prints shared object dependencies. The command's syntax is:

OPTIONS

Please note down the following points before going through the command:

ldd is installed by default in most Linux distributions. If you getting ldd command not found error, install it using:

Ubuntu / Debian

Redhat / CentOS Stream

Fedora

Arch

Let's look into some useful usages of ldd command.

We will display the dependencies of cp command.

We will display the dependencies of cp command with more details using -v option.

We can display unused direct dependencies of cp command using -u option.

We will display ldd works only on dynamic executables using -r option.

The output displayed a clear message state that the supplied file is not a dynamic executable.

When we try ldd on a standard command line executable like ls, We need full path to the dynamic executable.

We see that ldd states that it cannot find ls.

But with the absolute path, ldd worked fine.

To determine whether a given executable daemon supports TCP Wrapper or not, run the following command.

The output indicates that the OpenSSH (sshd) daemon supports TCP Wrapper.

We can use the ldd command when an executable is failing because of a missing dependency. Once we found a missing dependency, we can install it or update the cache with the ldconfig command.

We will perform relocations and report any missing objects (ELF only) by typing the command.

We will perform relocations for both data objects and functions, and report any missing objects or functions (ELF only) by typing the following command.

In this tutorial, we learned how to use ldd command with examples.

Thanks for reading, please provide your feedback and suggestions in the below comment section.

Navigate all-in-one place of Linux Commands for more learning.