29
[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.

5gon12eder
  • 24,280
  • 5
  • 45
  • 92
liam xu
  • 2,892
  • 10
  • 42
  • 65
  • 1
    Did you try reading ldd's man page? It tells you exactly what it does. – Sam Varshavchik Dec 23 '15 at 03:18
  • 4
    I know what it does, but I do not know where can I find linux-vdso.so.1 in my case(first line), and why there are no arrow pointed to /lib64/ld-linux-x86-64.so.2(last line). – liam xu Dec 23 '15 at 03:24

2 Answers2

33

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)"

Mike Frysinger
  • 2,827
  • 1
  • 21
  • 26
  • Could you elaborate on this? `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.` If `ldd` did output `/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2` for some binary, what does that indicate? The said binary had a dependency on the left hand side, and it's resolved to the right hand side..? – fy_iceworld Mar 07 '22 at 21:16
  • I have the same question as fy_iceworld. Specifically I have a case where the left-hand side (`/ld-linux-x86-64.so.2`) resolves to a different thing than the right-hand side: `/lib64/ld-linux-x86-64.so.2`. I've verified that these are not the same thing: $ sha1sum /ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2 3a70b2abfcae55144ad26d85c0f4be355e18b30e /ld-linux-x86-64.so.2 31352f5a6f6fddf0756aeff8a75f50772cb91ca7 /lib64/ld-linux-x86-64.so.2 – Aktau Nov 29 '22 at 11:05
6

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.

zedfoxus
  • 35,121
  • 5
  • 64
  • 63