Tracking Dependencies with ldd

I just learned about the ldd command and I wanted to share it with you. This might be useful if you’re trying to get control over a messy project by putting it in a container. A project lacking strict attention to dependencies and automation from the beginning often ends up a mess (we know this from helping a lot of customers clean up their messes). Getting a project like this running from a base Docker image requires a lot of work to figure out which dependencies need to be installed. ldd will help you find those dependencies.

So what do we have here? The first line of output says something about linux-vdso.so.1. New to you? Me too. An educated guess should get you pretty close. The vDSO is the Linux system library the kernel provides to applications. After the name of the library, we see a hex number. This is the address to which the library will be loaded when the program is run (modulo any relocations; more later). Interesting…

On the second line, we see libpthread.so.0. You guessed it - this is the POSIX threading library. We see it points to a file and an address. The file, of course, is the location of the library binary.

The third line is the same as the second but points at the libc library.

The last line is another interesting one: ld-linux-x86-64.so.2. I will leave it to the ld-linux man page:

>
> The programs ld.so and ld-linux.so* find and load the shared
libraries needed by a program, prepare the program to run, and then
run it.
>
>

So, the ld and ld-linux programs are akin to a boot and dependency injection process.

Finding unused and missing dependencies sure sounds useful when your system breaks down. I’m thankful I’ve never had to use this - these are some pretty low level concerns. More likely though I have had to use ldd but didn’t know it.

What are relocations the man page mentions? I hinted above that the hex address printed may be subject to change. Eli Bendersky has a great post about about the load-time relocation of shared libraries. The short story is a dynamic library can’t always know where its data will be located. Fixing this is part of the responsibility of the ld and ld-linux programs when they boot your program. Eli talks about how this happens in detail and talks about the modern solution that avoids the problem.

Finally, here’s how you might apply ldd to when getting control over a messy application: finding all the binary dependencies of your Ruby application. You can substitute this for your language of choice.