How to interpret the output of the ldd program?

Question

[root@wdctc1281 bin]#  ldd node         linux-vdso.so.1 =>  (0x00007fffd33f2000)         libdl.so.2 => /lib64/libdl.so.2 (0x00007f70f7855000)         librt.so.1 => /lib64/librt.so.1 (0x00007f70f764d000)         libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f70f7345000)         libm.so.6 => /lib64/libm.so.6 (0x00007f70f7043000)         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70f6e2d000)         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70f6c10000)         libc.so.6 => /lib64/libc.so.6 (0x00007f70f684f000)         /lib64/ld-linux-x86-64.so.2 (0x00007f70f7a61000) 

What does the first line and last line mean? They don't look like the normal

xxxx.so => /lib64/xxxxx.so (0xxxxxxxxxxxxxxxxxxxx) 

format.

Answer 1

the first line is the VDSO. this is described in depth in the vdso(7) manpage. basically it's a shared library that's embedded in your kernel and automatically loaded whenever a new process is exec-ed. that's why there's no filesystem path on the right side -- there is none! the file only exists in the kernel memory (well, not 100% precise, but see the man page for more info).

the last line is the ELF interpreter. this is described in depth in the ld.so(8) manpage. the reason it has a full path is because your program has the full path hardcoded in it. the reason it doesn't have an entry on the right side is that it's not linked against (directly) and thus no search was performed. you can check this by running:

$ readelf -l node | grep interpreter       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] $ scanelf -i node ET_EXEC /lib64/ld-linux-x86-64.so.2 node 

all the other lines are libraries you've linked against. you can see those by looking at DT_NEEDED tags when you run readelf -d on the file. since those files lack full paths, the ld.so needs to perform a dynamic path search for it. that's actually what the lines are telling you: "libdl.so.2 is needed, so when i searched for it, i found it at /lib64/libdl.so.2 (and was loaded into memory at address 0x00007f70f7855000)"