Dependencies VS libtree

I did some digging with Dependencies and found that issue is with libstdc++-6.dll

Maybe Dependency Walker can shed some light on that 🤔

I did that, basically. Problem is there is a clblast.dll (on windows) that llama.dll depends on, and it llama-cpp-python always failed dependency resolve to find it. I copied the dll to the right folder, loading it manually via CDLL worked fine, and https://github.com/lucasg/Dependencies also confirmed the dll was findable. When loading DLL's in windows, it checks the same folder for dependency dll's (and a few other places).

You can uses dependencies walker to detect the exact version of MS c++ runtime required.

If that doesn't work you will have to do it the hard way like i did. Using Dependencies to find the missing dlls

("Dependencies" is Dependencies.exe from https://github.com/lucasg/Dependencies)

If you're using MinGW or Cygwin and link in an arbitrary number of system libraries, then you need to ship those files as well. You can use Dependencies to list all DLLs your program is using, including transient dependencies.

A couple of them, yes. Someone else linked Dependencies which is much more modern and doesn't have some of the issues these older applications have. Thank you for the suggestions regardless.

Depends on your libc.

Search order:

glibc: rpath > LD_LIBRARY_PATH > runpath > ld.so.cache > default paths.

musl: LD_LIBRARY_PATH > rpath=runpath > default paths.

Search path inheritance:

glibc: rpaths are inherited: When exe depends on libx depends on liby, then liby first considers its own rpaths, then libx's rpaths, then exe's rpaths. HOWEVER if liby specifies runpath, it will not consider rpaths from parents.

musl: rpaths and runpaths are the same and always inherited.

I verified the glibc/musl sources when writing https://github.com/haampie/libtree

Libtree: Turns ldd into a tree; explains why shared libraries are found or not\ (42 comments)