[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.
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
)"
ldd filename
shows you the program shared libraries used by the file.
libc.so.6, for example, is libc shared object version 6, which sits in /lib64 and its memory location is 0x00007f70f684f000.
The last line talks about ld-linux-x86-64.so version 2 under /lib64. This fellow will find and load shared libraries node
needs. It will prep those libraries and run them. So, speaking in very crude terms, ld-linux-x86-64 is the runner. libc.so.6 and others are loaded and ldd
shows the location of those shared libraries and memory locations. That is my understanding.