动态库发布需同时解决编译和运行时两阶段路径问题：编译阶段用-i和-l/-l指定头文件与库位置；运行阶段须通过ld_library_path、ldconfig或patchelf配置加载器搜索路径，否则报“cannot open shared object file”。
动态库发布不是“扔个 .so 文件过去就完事”——别人编译能过，运行时大概率报 error while loading shared libraries: libxxx.so: cannot open shared object file。核心问题在于：编译器（gcc）和运行时加载器（ld-linux.so）查库路径是两套逻辑，必须分别处理。
编译阶段：让 gcc 找到头文件和库名
发布方只需提供两样东西：.h 头文件 + libxxx.so 动态库文件。使用者用 gcc 编译时，需显式指定：
-
-I/path/to/include：告诉编译器去哪找.h文件（比如add.h） -
-L/path/to/lib -lxxx：告诉链接器去哪找库、要链接哪个库（-lxxx对应libxxx.so） - 注意：
-L和-l必须成对出现；若库在当前目录，可写成gcc main.c -o app ./libxxx.so，跳过-L/-l组合
运行阶段：让系统加载器找到 libxxx.so
编译通过 ≠ 能运行。Linux 加载器默认只查 /usr/lib、/usr/local/lib 等固定路径，不会看 -L 指定的路径。解决方法有三种，按推荐顺序：
- 临时生效（调试/演示用）：
LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH ./app - 永久生效（仅限本机部署）：把
libxxx.so拷到/usr/local/lib，再执行sudo ldconfig - 最稳妥（分发给他人）：用
patchelf工具改写可执行文件的RUNPATH，例如patchelf --set-rpath '$ORIGIN/../lib' ./app，这样运行时会相对查找./../lib/libxxx.so
为什么不能直接拷贝到 /usr/lib？
看似简单，但风险明确：
- 普通用户无写权限，必须
sudo，容易污染系统环境 - 多个项目用同名库（如都叫
libutils.so）会冲突覆盖 - 卸载困难，残留文件难追踪
- 容器或 CI 环境中根本不可行
所以，除非你是系统级基础库维护者，否则别碰 /usr/lib。
发布包结构建议（直接给用户解压就能用）
别只丢两个文件。推荐打包成如下目录结构：
mylib-1.0/
├── include/
│ └── add.h
├── lib/
│ └── libadd.so
└── examples/
└── test.c
并在 examples/test.c 里写好示例编译命令注释，比如：
gcc -I../include -L../lib test.c -o test -ladd LD_LIBRARY_PATH=../lib ./test
真正的麻烦不在编译，而在运行时加载路径的传递——这个环节最容易被跳过，也最难排查。发布前务必自己用全新终端测试一遍 LD_LIBRARY_PATH 是否生效，别等用户报错才反应过来。
