Arch Linux User Repository

Note: this package ships the CPU version of llama.cpp release binaries, not the CUDA/ROCm/Vulkan etc.

Please note:

This package being updated several times a day upstream, the best way to get the most recent version for yourself is to run the following commands

sudo pacman -S devtools nvchecker
git clone https://aur.archlinux.org/llama.cpp-bin.git && cd llama.cpp-bin
pkgctl version upgrade
pkgctl build -i all

Please only flag it out of date in case the build is broken or missing features.

If you have suggestions to automate the upgrading and publishing or want to take over maintenance, I'm all ears :-)

Note: this package ships the CPU version of llama.cpp release binaries, not the CUDA/ROCm/Vulkan etc.

@tee Because upstream started shipping symlinks for some of the libraries provided, which were turned into regular files due to our use of the install command in the PKGBUILD and ldconfig (rightly) doesn't like that.

I've just pushed an update fixing the broken build besides this issue.

why is this error showing?

(5/5) installing llama.cpp-bin                                                          [##################################################] 100%
ldconfig: /usr/lib/libggml.so.0 is not a symbolic link

ldconfig: /usr/lib/libggml-base.so.0 is not a symbolic link

ldconfig: /usr/lib/libmtmd.so.0 is not a symbolic link

ldconfig: /usr/lib/libllama.so.0 is not a symbolic link

:: Running post-transaction hooks...

@neitsab no problem, and thanks - comaintainer works fine for me

@envolution Sorry I completely missed your comment! I just added you as a co-maintainer, feel free to take over the package:-) Thanks

@neitsab - I can take over maintenance and solve for the issue below

feel free to maintain ownership if you like, I would only need co-maintainer

Currently, with https://github.com/ggml-org/llama.cpp/releases/tag/b6022, this happens:

$ llama-cli -hf unsloth/Qwen3-0.6B-GGUF
[...]
llama_model_load_from_file_impl: no backends are loaded. hint: use ggml_backend_load() or ggml_backend_load_all() to load a backend before calling this function
[...]
main: error: unable to load model

From https://github.com/ggml-org/llama.cpp/issues/14302, I learnt that this is because the executable is looking for its shared libraries in (a) the directory of the executable, and (b) the current directory.

So, one way around this is to cd to /usr/lib before running llama-cli (or llama-server etc.). This works for me.

But probably a better way would be to update the PKGBUILD to put everything into the same directory (or maybe do something with symlinks to make it a bit less ugly, if possible).

@chocolateboy You're right, and it's not limited to our package: https://github.com/ggerganov/llama.cpp/issues/11123

I just pushed an updated version which installs the shared libraries in the right place. Now I get

% llama-cli --version
version: 4714 (38e32eb6)
built with cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 for x86_64-linux-gnu

Thanks for noticing.

@neitsab Thanks for the info.

FYI, this snapshot is missing some files:

$ llama-cli --version

/usr/bin/llama-cli: error while loading shared libraries: libllama.so: cannot open shared object file: No such file or directory