4 ms·

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.

stabbles 2y ago
See `man ld.so` for the search behavior. Note that there are inconsistencies between glibc and musl when it comes to rpath and runpath.
georgyo 2y ago
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.
- wpollock 2y ago
  On top of that, libraries can be linked by their SONAME and not the file name. (This is rarely done however.)
  - cylemons 2y ago
    I thought dynamic linking always uses the soname
    - bregma 2y ago
      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.
  - account42 2y ago
    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.
cryptonector 2y ago
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.
duped 2y ago
> 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.
wakawaka28 2y ago
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.
almostgotcaught 2y ago
> 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.
- rurban 2y ago
  Nope, only elf, no macho support.
rdtsc 2y ago
I think it wanted to say that is it shows how it found the dependency: LD_LIBRARY_PATH, rpath, etc.

stabbles 2y ago

See `man ld.so` for the search behavior. Note that there are inconsistencies between glibc and musl when it comes to rpath and runpath.

georgyo 2y ago

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.

wpollock 2y ago
On top of that, libraries can be linked by their SONAME and not the file name. (This is rarely done however.)
- cylemons 2y ago
  I thought dynamic linking always uses the soname
  - bregma 2y ago
    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.
- account42 2y ago
  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.

cryptonector 2y ago

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.

duped 2y ago

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

wakawaka28 2y ago

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.

almostgotcaught 2y ago

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

rurban 2y ago
Nope, only elf, no macho support.

rdtsc 2y ago

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