Libtree: Ldd as a tree saying why a library is found or not

I don't know what it means in the context of this tool, but library searching is much more complicated than a single environment variable.

There is the system search path, runpath, rpath, and LD_LIBRARY_PATH as just a few different distinct methods library searched on directories.

Libraries are also usually linked just by the short name, IE foo.so, but they can also be dynamically linked to the full path of the library.

Side note, as a general rule if you can avoid setting the LD_LIBRARY_PATH you'll be much off. It's not always possible, but setting puts it at the top of the search for all executions. Even if something dynamically links the full path to a library, LD_LIBRARY_PATH will take precedence. It completely flattens the search.

It is either in the LD_LIBRARY_PATH or it isn't?

at minimum you have RPATH, RUNPATH, LD_LIBRARY_PATH.

this tool is based on ldd and thus also (presumably) resolves DYLD_LIBRARY_PATH, DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_FALLBACK_LIBRARY_PATH, @executable_path, @loader_path and @rpath.

LD_LIBRARY_PATH is not the only way libraries are found. The loader considers several other sources to find libraries. Assuming a sane setup, this will be a combination of ordinary ELF fields in each binary that gets loaded and other paths known to the loader. Relying on LD_LIBRARY_PATH can be very short-sighted on systems with many versions of the same library or multiple libraries with the same name. The loader must search the paths in LD_LIBRARY_PATH for each binary in order, and it will pick the first library that matches (unless you have other higher-priority paths set by other means). That may not be the one you really want. This can lead to unexpected errors at runtime. The better way is to set RPATH for the affected binaries to the location that has the libraries that it requires.

It is possible to end up loading multiple versions of the same library as well, if your environment and RPATH settings are not consistent. This tool will help you figure out if you have problems and why.

I think it wanted to say that is it shows how it found the dependency: LD_LIBRARY_PATH, rpath, etc.

It is either in the LD_LIBRARY_PATH or it isn't

Or RPATH, which is evaluated at load time per each library. The bigger point is that dependencies form a graph (which can be displayed as a tree) and its useful to know why a library wasn't found because of the library that required it.

A library need not be in LD_LIBRARY_PATH in order to be found.

The point of the title is to say that libtree makes it easy to find the paths from an executable to all its direct and indirect dependencies, one of the uses of which is to help figure out what's up with missing dependencies.

In reality if you're using a packaging system then you likely won't have missing dependencies, so you'd use libtree for other reasons.

linux-vdso.so.1 isn't a real library you'll find anywhere in the file system and it's not referenced within the ELF file, so libtree doesn't know about it. Instead it is mapped into the address space of a newly started process automatically by the kernel. It's an optimization feature to avoid syscall overhead for function like gettimeofday. See https://man7.org/linux/man-pages/man7/vdso.7.html

I wrote something vaguely similar for python and we could never get around that issue https://github.com/google/importlab/issues/69

Recent (like 5+ years) versions of "ldd" will not invoke the target binary either.

See: https://manpages.debian.org/unstable/manpages/ldd.1.en.html#...

From a quick scan of the code, on mobile, it doesn't look like it does.

This seems to actually manually parse the ELF file and recursively parse any dependencies.

Pretty cool.

Or use objdump, which prints the data as it is encoded in the ELF file. Including the list of libraries the vdso will search for.

The first suggestion under the `# Install` header is to use a prebuilt binary like:

https://github.com/haampie/libtree/releases/download/v3.1.1/...

The only verification provided is a sha256sum provided in the README, there's no way to confirm what source code or compiler was used to produce the binary, and no way to verify the binary was produced by that github user / that the README sha256 I was served was untampered with.

I would propose that the 'unsafe' curl method is in fact probably safer than the recommended-first choice in the README.

The joke that kills lol

Yep, my thoughts exactly.

[1] https://www.dependencywalker.com/

Note that that particular tool doesn't work very well for modern Windows versions anymore.

Use https://github.com/lucasg/Dependencies instead (even though that isn't exactly up-to-date either...)

If you have Visual Studio installed (and have selected the 'x64/x86 build tools (latest)' in the installer), `dumpbin /dependents` from a VS Developer Command Prompt remains the most reliable option.

This is not a "static" evaluation of the library dependencies, it's a loader debug flag. So it's not quite the same thing.

It supports playing audio files; got added quite a few years back. :help sound-functions.

https://github.com/ReverseApple/dgraph but IIRC it still has some @rpath and its Apple extended family counterpart issues. PRs welcome!

Seems a bit harder to print a DAG in a terminal in a readable way, even if the output is shorter.