ldd on Mac: What otool -L Shows and What It Misses

On Linux, ldd ./program prints every shared library the program needs and where the loader will find it. On a Mac the same line gives this:

$ ldd /opt/homebrew/bin/llama-server
zsh: command not found: ldd

Every answer says to use otool -L. The accepted Stack Overflow answer to "what is the clang analogue of ldd?" is that one sentence. It is the right command, but it answers a smaller question than ldd does, and since macOS 11 it points at files that are not on disk. I ran it next to the other options (dyld_info, DYLD_PRINT_LIBRARIES, brew linkage and a recursive script from Stack Overflow) on this Mac mini (macOS 26.4.1). The test binary was Homebrew's llama.cpp server, which I already run for the Ollama vs llama.cpp server comparison.

otool -L lists what the binary asks for, not what it gets

otool comes with the Command Line Tools (/usr/bin/otool is a 119 KB stub that hands off to /Library/Developer/CommandLineTools/usr/bin/otool). It reads the load commands in the file and prints them:

$ otool -L /opt/homebrew/bin/llama-server
/opt/homebrew/bin/llama-server:
	@rpath/libllama-server-impl.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libllama-common.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmtmd.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libllama.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/homebrew/opt/ggml/lib/libggml.0.dylib (...)
	...
	/usr/lib/libc++.1.dylib (...)
	/usr/lib/libSystem.B.dylib (...)

That is 12 entries, and the differences from ldd are already visible:

• Direct dependencies only. ldd walks the whole tree. otool -L stops at one level. llama-server loads Homebrew's libomp.dylib, but it is not in this list. It comes in through libggml-base.0.dylib, two levels down.
• Unresolved names. Four entries start with @rpath/. otool prints the name as stored and does not search. The binary's search path is a separate load command, which you see with otool -l llama-server | grep -A2 LC_RPATH. Here it is @loader_path/../lib. This is the complaint in a 2018 question that still has no accepted answer: otool reports where a dependency should be, not where the loader finds it.
• No "not found". ldd marks a missing library. otool -L prints the same line whether the file exists or not.

Three smaller traps showed up in scripts. Run on a dylib, otool -L prints the library's own install name as the first entry, so counting lines overcounts by one. On a universal binary it shows only the slice for the current machine, with no label. otool -arch all -L shows both. On a file that is not Mach-O, such as /etc/hosts, it prints "is not an object file" and exits 0.

Since Big Sur, the system libraries are not files

The /usr/lib paths in that output do not exist:

$ ls -l /usr/lib/libSystem.B.dylib
ls: /usr/lib/libSystem.B.dylib: No such file or directory
$ otool -L /usr/lib/libSystem.B.dylib
error: .../otool-classic: can't open file: /usr/lib/libSystem.B.dylib (No such file or directory)

Apple's macOS Big Sur 11.0.1 release notes explain it. The system now ships "a built-in dynamic linker cache of all system-provided libraries", and "copies of dynamic libraries are no longer present on the filesystem." On this Mac, /usr/lib holds 12 .dylib files. The cache map in /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/ lists 3,643 images, 410 of them under /usr/lib/. Any script that follows otool output with a file check, or calls otool again on each result, fails on every system library.

dyld_info, which is in /usr/bin on current macOS, reads from the cache:

$ dyld_info -linked_dylibs /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib [arm64e]:
    -linked_dylibs:
        attributes     load path
        re-export      /usr/lib/system/libcache.dylib
        ...
$ dyld_info -platform /usr/lib/libnope.dylib; echo $?
dyld_info: '/usr/lib/libnope.dylib' file not found
1

That exit code makes it a usable "does this library exist" check. It also lists every architecture by default, and dyld_info -dlopens shows dlopen() calls. For libggml.0.dylib it found one but could only say <unknown>, because the path is built at runtime.

DYLD_PRINT_LIBRARIES runs the program, and macOS 26 inflates it

The other common answer is to let the loader report what it loads:

$ DYLD_PRINT_LIBRARIES=1 /opt/homebrew/bin/llama-server --version
dyld[90742]: <37F89FC6-...> /opt/homebrew/Cellar/llama.cpp/0.4.0/bin/llama-server
dyld[90742]: <D6444E5C-...> /opt/homebrew/Cellar/llama.cpp/0.4.0/lib/libllama-server-impl.dylib
...

This is the only method that resolves everything, including @rpath and the five ggml backends loaded with dlopen from ggml/libexec. It has three problems.

First, it runs the binary. I compiled a test program that writes a file, and the file appeared. The Linux ldd man page warns that ldd itself may run code and should "never" be used on an untrusted executable. On a Mac, otool and dyld_info never run the target, but this method always does.

Second, it prints nothing for Apple's binaries. DYLD_PRINT_LIBRARIES=1 /bin/ls gave 0 lines. Apple's System Integrity Protection guide says dyld environment variables "are purged when launching protected processes". A copy of ls in /tmp also printed nothing, because the Apple platform signature is copied with the file. Removing or replacing the signature got the copy killed (exit 137). The dtrace SIP warning is the same wall from another tool, and launchctl setenv drops DYLD_ variables before they reach a job.

Third, the line count is wrong on macOS 26. A hello-world C program that links only libSystem produced 600 image lines. The same run also printed 555 lines of move loaded to delayed: CoreFoundation and similar. Inside the process, _dyld_image_count() returned 45, which is 600 minus 555. dyld lists a large graph and then marks most of it as not needed yet. If you grep -c the output, you get a number about 13 times too high. For llama-server it was 645 lines and 253 delayed, so 392 images.

The recursive scripts on Stack Overflow

The recursive otool question (10,760 views) has an accepted answer that says "you'll have to run otool repeatedly" and gives a short Python loop. The author notes it does not handle @executable_path, canonical paths or spaces. I ported it to Python 3 by changing two lines and ran it on llama-server. It returned 16 entries. Five were raw @rpath/... strings, and libcrypto.3.dylib appeared twice, once through opt/ and once through Cellar/. stderr had 9 "can't open file" errors: one for each system library, which is the Big Sur change, and one for each @rpath name. It did find libomp, because libggml is referenced by an absolute path.

brew linkage llama.cpp is the Homebrew answer, and it does resolve paths. It reports per formula, though, so it did not show libomp, which belongs to ggml. It also prints "linkage is a developer command, so Homebrew's developer mode has been automatically turned on". That setting stays on until you run brew developer off.

A 52-line ldd for macOS that does not run the binary

This is the script I use now. It runs on the stock /usr/bin/python3 and calls only otool and dyld_info. It expands @rpath (search paths add up down the load chain, and @loader_path inside one means the library that declared it), @loader_path and @executable_path. It skips a library's own ID, removes duplicates by real path and checks cache-only libraries with dyld_info:

#!/usr/bin/python3
"""lddm: ldd-style recursive dependency list for Mach-O, without running the binary."""
import os, re, subprocess, sys

def otool(flag, path):
    r = subprocess.run(["otool", flag, path], capture_output=True, text=True)
    return r.stdout if r.returncode == 0 else ""

def deps(path):
    lines = otool("-L", path).splitlines()[1:]
    out = [l.strip().split(" (compatibility")[0] for l in lines if l.strip()]
    ident = otool("-D", path).splitlines()[1:]          # dylibs list their own id first
    return [d for d in out if not ident or d != ident[0].strip()]

def rpaths(path):
    return re.findall(r"cmd LC_RPATH\n\s+cmdsize \d+\n\s+path (.+?) \(offset", otool("-l", path))

def sub(p, loader, exe_dir):
    return p.replace("@executable_path", exe_dir).replace("@loader_path", os.path.dirname(loader))

def resolve(name, loader, exe_dir, rps):
    if name.startswith("@rpath/"):
        for rp in rps:
            cand = os.path.join(rp, name[len("@rpath/"):])
            if os.path.exists(cand):
                return os.path.realpath(cand)
        return None
    cand = sub(name, loader, exe_dir)
    return os.path.realpath(cand) if os.path.exists(cand) else cand

def walk(path, exe_dir, inherited, seen, depth):
    # rpaths accumulate down the load chain; @loader_path in an rpath means
    # the image that declared it, so expand before passing it on
    rps = inherited + [sub(r, path, exe_dir) for r in rpaths(path)]
    for name in deps(path):
        real = resolve(name, path, exe_dir, rps)
        if real is None:
            print("  " * depth + f"{name} => not found"); continue
        if real in seen: continue
        seen.add(real)
        if not os.path.exists(real):        # system libs live only in the dyld shared cache
            in_cache = subprocess.run(["dyld_info", "-platform", real],
                                      capture_output=True).returncode == 0
            print("  " * depth + f"{name} => " + ("(dyld shared cache)" if in_cache else "not found"))
            continue
        print("  " * depth + f"{name} => {real}")
        walk(real, exe_dir, rps, seen, depth + 1)

for target in sys.argv[1:]:
    exe = os.path.realpath(target)
    print(f"{target}:")
    walk(exe, os.path.dirname(exe), [], set(), 1)

$ lddm /opt/homebrew/bin/llama-server
/opt/homebrew/bin/llama-server:
  @rpath/libllama-server-impl.dylib => /opt/homebrew/Cellar/llama.cpp/0.4.0/lib/libllama-server-impl.dylib
    @rpath/libllama-common.0.dylib => /opt/homebrew/Cellar/llama.cpp/0.4.0/lib/libllama-common.0.4.0.dylib
      @rpath/libllama.0.dylib => /opt/homebrew/Cellar/llama.cpp/0.4.0/lib/libllama.0.4.0.dylib
        /opt/homebrew/opt/ggml/lib/libggml.0.dylib => /opt/homebrew/Cellar/ggml/0.23.0/lib/libggml.0.23.0.dylib
          @rpath/libggml-base.0.dylib => /opt/homebrew/Cellar/ggml/0.23.0/lib/libggml-base.0.23.0.dylib
            /usr/lib/libSystem.B.dylib => (dyld shared cache)
            /opt/homebrew/opt/libomp/lib/libomp.dylib => /opt/homebrew/Cellar/libomp/23.1.0/lib/libomp.dylib
...

The 9 Homebrew libraries it resolved are the same 9 that dyld loaded at startup. The only ones missing are the 5 dlopen backends, and Linux ldd misses those too. For a missing library, I built a test app with an @rpath dependency in a folder with a space in its name and then moved the dylib away. lddm printed @rpath/libfoo.dylib => not found. Running the app gave dyld's own error, which lists every path it tried:

dyld[92197]: Library not loaded: @rpath/libfoo.dylib
  Referenced from: <21F44A44-...> /private/tmp/lddlab/sp ace/bin/app
  Reason: tried: '/private/tmp/lddlab/sp ace/bin/../lib/libfoo.dylib' (no such file), ...

That error message is the closest thing macOS has to ldd's "not found" line, and it is often the fastest answer when a program won't start. The script does not cover DYLD_LIBRARY_PATH/DYLD_FALLBACK_LIBRARY_PATH or weak links. It also reads only the slice otool picks for this machine. Like the realpath on Mac write-up, the missing command is the easy part. The real gap is the behavior people expect to come with it.

Sources: every command ran on 2026-10-03 on a Mac mini (Mac16,10, macOS 26.4.1 build 25E253, SIP enabled) with otool from Command Line Tools cctools-1040, /usr/bin/dyld_info, Homebrew llama.cpp 0.4.0 and ggml 0.23.0, in a throwaway folder under /tmp that has since been deleted. The image counts come from DYLD_PRINT_LIBRARIES output checked against _dyld_image_count() in the same process, and the cache figure from the arm64e shared cache .map file. The "delayed" lines are what dyld printed. I did not find Apple documentation for them, so their meaning here is inferred from that count. Stack Overflow view counts come from the Stack Exchange API on the same day. The 1517614 script was tested after a minimal Python 3 port, so its results describe that port. I did not test on Intel Macs or on macOS versions older than 26.4.1.