Compile bug:

快速结论：Compile bug: 这类问题通常出现在 llama.cpp 使用 cmake 编译并执行 make install 时：启用动态后端加载（-DGGML_BACKEND_DL=ON）后，后端库 libggml-blas.so、libggml-cpu.so、libggml-cuda.so 会被安装到 $CMAKE_INSTALL_PREFIX/bin（例如 /usr/bin），而不是常规的 lib 目录。优先确认是否启用了 GGML_BACKEND_DL，以及你期望的后端库安装路径是否与 loader 的搜索顺序一致。

适用环境：Issue 中确认的环境为 Linux、GGML backend 使用 CUDA、llama.cpp Release 0.6.0；编译时启用了 GGML_BLAS=ON、GGML_BACKEND_DL=ON、GGML_CUDA=ON、GGML_CUDA_FORCE_CUBLAS=ON、GGML_CUDA_ENABLE_UNIFIED_MEMORY=1，并设置了 -DCMAKE_INSTALL_PREFIX=/usr 与 -DCMAKE_INSTALL_LIBDIR=lib$LIBDIRSUFFIX。

最快修复方案：如果希望把动态后端库安装到自定义目录，Issue 中维护者给出的明确方法是编译时指定 -DGGML_BACKEND_PATH 宏，后端库会安装到该路径。除此之外，Issue 中没有任何已验证的一步修复方案来改变默认的 bin 安装行为。

注意事项：维护者说明后端 loader 会按以下顺序查找动态后端库：1）GGML_BACKEND_PATH 编译宏；2）/proc/self/exe 所在目录；3）当前工作目录。因此，如果只是手动把 libggml-cuda.so 等文件移动到 lib 目录，而没有同时设置 GGML_BACKEND_PATH 或调整 loader 搜索路径，很可能出现 “unable to load CPU backend” 之类的加载失败。Issue 中关于把默认路径改为 /usr/lib64/llama.cpp/backends/ 的说法只是讨论中的提议，并未确认落地，不要当作已有功能使用。

问题场景

用户在 Linux 上从源码编译 llama.cpp Release 0.6.0，使用 CMake 配置 CUDA、BLAS 与动态后端加载，然后执行 make install/strip DESTDIR=$PKG。安装完成后发现大部分共享库位于 /usr/lib64，但三个动态后端库被安装到了 /usr/bin：

/usr/bin/libggml-blas.so
/usr/bin/libggml-cpu.so
/usr/bin/libggml-cuda.so

用户认为这不符合 GNU/Linux 共享库的常见布局，因为这些是运行时动态加载的 backend，而不是可直接执行的程序，因此提出了 Compile bug: 类型的安装路径问题。

报错原文

Compile bug:

Make install installs
/usr/bin/libggml-blas.so
/usr/bin/libggml-cpu.so
/usr/bin/libggml-cuda.so

Shared libraries usually do not go to `/usr/bin` on GNU/Linux.
Is there a reason for doing that?
These are the so-called "backends", which are loaded dynamically in runtime.

讨论中还出现了与后端加载失败相关的典型错误描述：

unable to load CPU backend...

原因分析

可能原因与 GGML_BACKEND_DL=ON 的安装布局有关。启用动态后端加载后，llama.cpp 需要让主程序在运行时找到并 dlopen 这些 backend 共享库。维护者在讨论中解释，后端库被放在 bin 目录，是因为二进制程序需要能在同一目录下找到它们；否则用户会遇到类似 “unable to load CPU backend…” 的错误。

另一个关键点是 CMake 的 CMAKE_INSTALL_PREFIX 只决定安装的基础前缀，不保证所有文件都直接落在该前缀根目录。因此，即使用户设置了 -DCMAKE_INSTALL_PREFIX=/usr，普通共享库进入 /usr/lib64，而动态 backend 进入 /usr/bin，在 CMake 行为上并不矛盾。

Issue 中没有给出代码层面的 bug 确认，标签也是 bug-unconfirmed。因此这里更准确的说法是：这是 llama.cpp 当前安装布局与 GNU/Linux 共享库惯例之间的差异，而不是已确认的编译错误。

环境排查

确认 llama.cpp 版本或 Git commit：Issue 中为 Release 0.6.0。
确认操作系统：Issue 中为 Linux。
确认 GGML backend：Issue 中为 CUDA。
确认 CMake 配置中是否启用了 -DGGML_BACKEND_DL=ON。
确认是否设置了 -DCMAKE_INSTALL_PREFIX=/usr 以及 -DCMAKE_INSTALL_LIBDIR=lib$LIBDIRSUFFIX。
确认安装后 libggml-blas.so、libggml-cpu.so、libggml-cuda.so 的实际位置，以及主程序是否能通过 loader 搜索路径找到它们。
确认是否已设置 GGML_BACKEND_PATH 编译宏；Issue 中的做法是使用 -DGGML_BACKEND_PATH 指定后端库安装路径。
Issue 中未提供 Python、PyTorch、具体显卡型号等信息，不需要补写这些项目。

解决步骤

先确认问题是否由 GGML_BACKEND_DL=ON 引起：检查 CMake 缓存或编译命令中是否包含该选项。
如果只是希望自定义后端库安装位置，在 CMake 配置阶段加入 -DGGML_BACKEND_PATH=<你的路径>。Issue 中维护者明确表示该宏会让后端库安装到指定路径。例如若你希望放在 /usr/lib64/llama.cpp/backends/，应按该宏的实际取值方式配置，而不是仅在安装后手动移动文件。
如果不使用 GGML_BACKEND_PATH，则需要接受当前 loader 的搜索顺序：1）GGML_BACKEND_PATH 编译宏；2）/proc/self/exe 所在目录；3）当前工作目录。也就是说，默认情况下后端库需要位于可执行文件同目录，或者从当前工作目录被找到。
如果打算改变 llama.cpp 的默认安装布局，Issue 中维护者的态度是：可以提交 PR。讨论里提到过将 GGML_BACKEND_PATH 定义为 /usr/lib64/llama.cpp/backends/ 的想法，但这只是提议，并未在该 Issue 中确认合并。
不要仅凭本 Issue 就断定 /usr/bin 安装是编译 bug；Issue 关闭时标签仍为 bug-unconfirmed，没有确认的代码修复。

验证方法

重新安装后检查 backend 共享库的实际落点：如果使用了 GGML_BACKEND_PATH，确认 libggml-blas.so、libggml-cpu.so、libggml-cuda.so 出现在指定路径下。然后运行 llama.cpp 主程序并加载 CUDA backend，确认不再出现 unable to load CPU backend... 或类似 backend 加载失败信息。若没有设置 GGML_BACKEND_PATH，则确认这些库是否与可执行文件位于同一目录，或位于当前工作目录，以匹配 loader 的搜索顺序。