（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40626969

这个名为 libtree 的工具简化了查找可执行文件及其直接和间接依赖项之间的路径。通过这样做，它有助于确定缺失的依赖关系，使问题识别更容易。尽管它主要是为 Linux 环境设计的，但它支持多种方式来定位 LD\_LIBRARY\_PATH 之外的库。根据设置，此工具可以解析 DYLD\_LIBRARY\_PATH、DYLD\_FALLBACK\_FRAMEWORK\_PATH、DYLD\_FALLBACK\_LIBRARY\_PATH、@executable\_path、@loader\_path 和 @rpath。但是，由于查找必要库的限制和潜在冲突，仅依赖 LD\_LIBRARY\_PATH 可能会导致意外问题。相反，将各个二进制文件的 RPATH 设置到其所需位置是首选解决方案。 Libtree 可以帮助发现这些复杂性并协助解决它们。 libtree 列出的依赖项与通过 ldd 获取的依赖项之间存在差异，可能是由于 libtree 基于 ldd 同时提供了附加功能。当处理需要同一库的多个版本的二进制文件时，环境和 RPATH 设置之间的不一致可能会导致运行时出现不可预见的错误。该工具是处理此类情况的宝贵资源。尽管它与 ldd 的结果有所不同，但它提供了一些好处，包括易于使用和增强的功能。此外，它的使用只需调用程序，无需任何广泛的配置或安装。

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.

Having to recursively and iteratively hunt missing dependencies with ldd can be pretty tedious. So this seems like a good improvement. Will try it next time I get an obscure not found

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.

In case anyone else is wondering what the colors mean (I couldn't find this in the manpage/README):

Magenta: In exclude list (only shown with -v[v[v]])

Blue: Seen before (so you can spot which dependencies appear multiple times)

What does "why a library is found or not" mean? It is either in the LD_LIBRARY_PATH or it isn't? The screenshot doesn't make it clear to me what this refers to.

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.

The SONAME is the filename used for runtime linking. On the filesystem it may or may not be a symlink but that does not concernt the linker. It may not be (and usually isn't) the same filemame used when bulding the binary. This is because the SONAME is meant to specify a specific ABI version of the library.

Static linking uses the DT_SONAME of a linked library to create an entry in the DT_NEEDED table. The name in the DT_NEEDED table is used by the dynamic loader to search for a matching filename to load in. So in a very indirect sense the dynamic loader always uses the SONAME that was supplied at build time, but it also uses a search algorithm to find that filename at load time.

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.

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

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

Not sure if it's a bug, but I get different libraries from ldd and libtree for the vim example (e.g. linux-vdso.so.1 appears top of the list on ldd but not at all on libtree)

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

linux-vdso.so is mostly about sharing a data page so syscalls can be optimised away. It's not for all the kernel API entry points (and it's userland specific so the VDSO varies with the libc version according to which features it optimises in this way). For the specific example above gettimeofday() - each process can read the clock value straight out of the shared VVARS page mapped into its space, no expensive context switch.

Well, yes, it is a real file, but it is always mapped (at least it used to) into every process' memory space, even if you don't import it explicitly, and it provides a user-space layer above the low-level syscalls.

i wrote a horrible little script to use ldd recursively on nixos to figure out what I need to include to run a closed source binary, will give this one a go if I ever try that again.

The original joke was to define an alias

    alias libtree='curl -LfSs https://raw.githubusercontent.com/haampie/libtree/master/libtree.c | ${CC:-cc} -o /tmp/libtree -x c - -std=c99 -D_FILE_OFFSET_BITS=64; /tmp/libtree'

so any time you invoke `libtree` it downloads the latest version, compiles it, and runs it.

With a stable internet connection, it is still faster than pax-util's lddtree, which is written in Python.

C is an excellent scripting language.

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.

Usually people compile a "hello world" exe, and implicitly extrapolate that size to all programs of all sizes.

...which is then followed by arguments about how libc's own size should be compared to other libs that need to be linked statically and do a different amount of work.

（评论） (comments)

（评论）
(comments)