报/usr/bin/ld: cannot find -lxxx是链接阶段失败，非环境变量未生效所致；gcc仅通过-L、LIBRARY_PATH及默认路径（如/usr/lib）查找库，不读LD_LIBRARY_PATH；可用gcc -lxxx --verbose | grep search验证实际搜索路径。
gcc编译时报 /usr/bin/ld: cannot find -lxxx 怎么定位
这不是环境变量没生效，而是链接器根本没去你认为的路径里找。gcc本身不直接查 LD_LIBRARY_PATH，它只认 -L、LIBRARY_PATH 和内置默认路径（如 /usr/lib）。报这个错时，ld 已经跳过了运行时路径，纯粹是编译链接阶段失败。
快速验证方法：
- 运行
gcc -lhdf5 --verbose 2>&1 | grep "search"，看输出里有没有你期望的库路径 - 用
find /opt -name "libhdf5.so*" 2>/dev/null确认库文件真实存在位置 - 检查该路径下是否真有
libxxx.so或libxxx.a（注意：仅.so不够，链接阶段需要.so或.a；若只有.so.1.12.0，需加软链libxxx.so → libxxx.so.1.12.0）
LIBRARY_PATH 和 LD_LIBRARY_PATH 到底该设哪个
LIBRARY_PATH 是给 gcc 链接器用的，LD_LIBRARY_PATH 是给程序运行时动态加载器用的——两者完全不互通。设错就白配。
- 编译时报
cannot find -lxxx→ 只改LIBRARY_PATH或加-L/path/to/lib - 编译通过但运行时报
error while loading shared libraries→ 只改LD_LIBRARY_PATH或用-Wl,-rpath - 同时设两个？可以，但别混淆用途；
export LIBRARY_PATH=/my/lib:$LIBRARY_PATH才有效，export LD_LIBRARY_PATH=/my/lib:$LD_LIBRARY_PATH对编译无用
cmake 项目里库路径没被识别，常见漏点
cmake 不会自动读取 LIBRARY_PATH 或 LD_LIBRARY_PATH，它靠自己的变量和命令驱动。
-
find_package(XXX)找不到？优先试cmake -DCMAKE_PREFIX_PATH=/path/to/xxx ..，而不是改 shell 环境变量 -
link_directories()已被 cmake 官方标记为“不推荐”，应改用target_link_libraries(target PRIVATE xxx::xxx)或显式传-L给 linker - 用
message(STATUS "LIBRARY_DIRS: ${CMAKE_LIBRARY_PATH}")打印 cmake 内部变量，确认它是否真拿到了你设的路径 - 如果库在非标准子目录（比如
/opt/hdf5/lib64），find_package(HDF5)默认只查lib/，得额外加HDF5_ROOT或手动set(HDF5_LIBRARIES "/opt/hdf5/lib64/libhdf5.so")
为什么 export 了还是不生效
最常踩的坑不是命令写错，而是作用域和 shell 类型不匹配。
-
export只对当前 shell 及其子进程有效；新开终端或sudo make会丢失 —— 永久生效必须写进~/.bashrc（bash）或~/.zshrc（zsh），然后source或重启 shell - 某些构建系统（如 ninja、make -j）会清空或重置环境变量，尤其 Jenkins 或容器里；此时硬编码
-L或-Wl,-rpath更可靠 -
sudo默认不继承用户环境变量（除非加-E），所以sudo make时LIBRARY_PATH为空 —— 改成sudo env "LIBRARY_PATH=$LIBRARY_PATH" make或直接避免 sudo 编译 - 确认 shell 类型：
echo $SHELL，别在 zsh 里改.bashrc，也别在 root 下改普通用户的配置文件
真正麻烦的从来不是“怎么配”，而是配完之后不知道哪个环节悄悄绕过了它 —— 动手前先用 gcc --verbose 或 cmake -L 把实际生效的路径打出来，比反复 export 有用得多。
