ldd(1)

💖 ldd(1) — print shared object dependencies 💖

okay bestie, welcome to ldd, a classic from the General Commands Manual section (that's section 1, the "commands you actually type" girlies). she's small, she's powerful, she tells you exactly which shared libraries your programs are leaning on. no cap. 🫶

---

✨ NAME ✨

ldd — print shared object dependencies

🌸 SYNOPSIS 🌸

ldd [option ...] file ...

🦋 DESCRIPTION 🦋

so what does ldd actually do?? she prints the shared objects (aka shared libraries, the besties your program links against at runtime) that each program or shared object you pass on the command line needs. like, every file you give her, she tells you what it depends on. iconic.

here's an example of her in action, and what the output looks like:

$ ldd /bin/ls;
    linux-vdso.so.1 (0x00007ffcc3563000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f87e5459000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00007f87e5254000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f87e4e92000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f87e4c22000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f87e4a1e000)
    /lib64/ld-linux-x86-64.so.2 (0x00005574bf12e000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00007f87e4817000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f87e45fa000)

how she does it, in the usual case: ldd invokes the standard dynamic linker (go read ld.so(8) bestie) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1. that little env var makes the dynamic linker peek at the program's dynamic dependencies, and then find (following the exact rules laid out in ld.so(8)) and load up the objects that satisfy those deps. for every single dependency, ldd shows you the location of the matching object and the (hexadecimal) address where it's loaded. ✨✨✨

quick lil note: the linux-vdso and ld-linux shared dependencies are special little guys — check vdso(7) and ld.so(8) for the lore 💫

---

🔒 Security 🔒

okay now the serious part, and I need you to actually listen because this one matters. in some circumstances (for example, when the program specifies an ELF interpreter that isn't ld-linux.so), some versions of ldd may try to grab the dependency info by directly executing the program. which can mean executing whatever code is defined in the program's ELF interpreter — and possibly executing the program itself too. yikes. 😭 (before glibc 2.27, the upstream ldd implementation did exactly this, for example, though most distributions shipped a modified version that did not.)

so: you should NEVER use ldd on an untrusted executable, because it can result in the execution of arbitrary code. like, fr fr. a safer alternative when you're dealing with untrusted executables is:

$ objdump -p /path/to/program | grep NEEDED;

⚠️ but heads up though: this alternative only shows the direct dependencies of the executable, whereas ldd shows the entire dependency tree of the executable. so it's safer but it's giving less. trade-offs, bestie. 💅

---

👑 OPTIONS 👑

• --version — print the version number of ldd. that's it, that's the whole thing.
• --verbose, -v — print ALL the information, including (for example) symbol versioning information. she's not holding back, she's spilling everything.
• --unused, -u — print unused direct dependencies. (since glibc 2.3.4, so she's been doing this for a min 💜)
• --data-relocs, -d — perform relocations and report any missing objects. (ELF only)
• --function-relocs, -r — perform relocations for BOTH data objects and functions, and report any missing objects or functions. (ELF only)
• --help — usage information. the classic, the icon, the "help me pls" flag 🎀

---

💀 BUGS 💀

• ldd does not work on a.out shared libraries. nope. not happening. 🙈
• ldd also does not work with some extremely old a.out programs — the ones built before ldd support was even added to the compiler releases. if you run ldd on one of these, the program will attempt to run with argc = 0 and the results will be unpredictable. so like… don't? 🚩

---

🌈 SEE ALSO 🌈

pldd(1), sprof(1), ld.so(8), ldconfig(8)

---

so yeah that's ldd, she's tiny, she's nosy, she knows what your binaries are linked to. go check your deps bestie, and stay safe out there (seriously, not on untrusted executables, I'm begging 🥺).

mwah 💋 this page came to you from Linux man-pages 6.20, dated 2026-02-08.