This release completes the fix introduced in v1.5.3: build-tree llama-server binaries carry an absolute RUNPATH into ~/llama.cpp/build/bin, so copying the binary alone left it dependent on the build directory. When the CMake cache was cleaned, its shared libraries (e.g. libllama-server-impl.so) disappeared and the server exited immediately with code 127 (“error while loading shared libraries”).
What’s Fixed:
- Full Runtime Independence:
llama-serveris now installed together with all of its local shared libraries as a runtime set into the LlamaTray-managed directory~/.local/lib/llamatray/llama.cpp; cleaning the build directory can no longer break the installation. - Atomic Launcher Entry Point:
~/.local/bin/llama-serveris now a real launcher file (never a symlink) that setsLD_LIBRARY_PATHto the runtime directory and execs the real binary — the same proven architecture already used by Option B prebuilt installs. - Legacy State Migration: Old broken states (symlinks into the build dir, bare binaries whose RUNPATH is bound to it, or unhealthy launchers) are automatically migrated to the standalone runtime set when the manager opens or before any cache cleanup; external symlinks and healthy installations are left untouched.
- End-to-End Verification: The installed entry point is verified after installs/cleanups and when the manager opens: real file (not a symlink), ELF runtime binary, no RUNPATH into the build dir, clean
ldd(no “not found”, nothing resolving from the build dir) and a fullllama-server --helprun; the result is logged. - Post-Cleanup Re-Verification: After every build cache cleanup the installed runtime set is re-checked to make sure it still works with the build directory absent.