gcc -shared 编译时报“cannot find -lxxx”是链接阶段错误，因在生成动态库时误加了-l选项；正确流程是先-fpic编译为.o，再用gcc -shared合并.o生成.so，-l仅用于最终可执行程序链接。
gcc -shared 编译时报“cannot find -lxxx”
这是链接阶段报错，不是动态库生成失败，而是你在用 gcc -shared 生成 .so 时，错误地加了 -lxxx 这类链接选项。动态库本身是被链接的“目标”，不是去链接别人的主体。
正确做法是：先用 -fPIC 编译源码为位置无关目标文件，再用 gcc -shared 合并这些 .o 文件 —— 中间不经过任何 -l 或 -L。
- 错误命令：
gcc -shared -fPIC calc.c -o libcalc.so -lm（-lm在这里无意义，且可能触发 ld 报cannot find -lm） - 正确流程：
gcc -c -fPIC calc.c -o calc.o→gcc -shared -o libcalc.so calc.o - 若你的动态库内部调用了其他库（比如 math 函数），必须在**最终可执行程序链接时**加
-lm，而不是在生成.so时加
生成的 .so 文件无法被 ldd 识别或提示 “not a dynamic executable”
说明生成的文件根本不是合法的 ELF 共享对象，常见原因是漏了 -fPIC 或没用 -shared。
验证方式：file libxxx.so 应输出包含 shared object 字样；readelf -h libxxx.so | grep Type 应显示 ET_DYN（而非 ET_REL）。
-
ET_REL：只是重定位目标文件（即普通.o），没加-shared - 没
-fPIC：x86_64 下 gcc 会直接报错；但某些旧版本或 i386 可能静默生成，导致运行时报cannot apply additional relocation - 混淆静态库命令：用
ar打包出的是.a，不是.so，ldd对它完全无效
生成成功但程序运行时报 “libxxx.so: cannot open shared object file”
这是运行时问题，和生成过程无关，但容易误以为是“生成失败”。本质是动态链接器找不到该文件。
关键排查点不是“怎么生成”，而是“怎么让系统知道它在哪”。LD_LIBRARY_PATH 对编译（gcc）无效，只影响运行时；真正控制链接阶段找库的是 -L 和 LIBRARY_PATH。
- 临时验证：
export LD_LIBRARY_PATH=/path/to/your/lib:$LD_LIBRARY_PATH再运行程序 - 永久生效：把路径写入
/etc/ld.so.conf.d/mylib.conf，然后sudo ldconfig - 一劳永逸（推荐部署用）：
gcc -o app main.c -L/path/to/lib -lxxx -Wl,-rpath,/path/to/lib——-Wl,-rpath把路径硬编码进可执行文件
nm -D 显示符号为空或关键函数缺失
说明你虽然生成了 .so，但导出符号不符合预期。C++ 项目尤其容易踩坑：默认所有符号都是隐藏的，除非显式声明 extern "C" 或使用 __attribute__((visibility("default")))。
例如，一个 C++ 函数 int add(int, int) 在未加 extern "C" 时，会被 mangling 成类似 _Z3addii，而 C 程序用 dlsym 查 "add" 肯定失败。
- C 接口：头文件里用
#ifdef __cplusplus包裹extern "C" - C++ 接口：用
__attribute__((visibility("default")))标记导出函数，且编译时加-fvisibility=hidden - 验证导出符号：
nm -D libxxx.so | grep add，应看到T add（非U或W）
-fPIC）、链接生成（-shared）、运行加载（rpath/ldconfig）。每个阶段的参数和环境变量各司其职，混用就会白忙半天。
