gcc链接动态库需指定-L路径和-l库名，但运行时仍需LD_LIBRARY_PATH或-Wl,-rpath确保找到libmylib.so；编译时漏加-fPIC、链接时误用-shared、忽略--no-as-needed等参数均会导致失败；可用ldd和readelf验证是否真正链接成功。
gcc链接动态库的基本命令格式
直接用 gcc 链接动态库，核心是两步：告诉编译器“去哪找库”、告诉它“要链哪个库”。最简形式就是：
gcc main.c -L./lib -lmylib -o main
其中：-L./lib 指定库文件所在目录（比如当前目录下的 lib/ 文件夹），-lmylib 表示链接名为 libmylib.so 的动态库（注意自动补前缀 lib 和后缀 .so）。
这个命令只完成**编译+链接**，生成的可执行文件仍需在运行时能找到 libmylib.so，否则会报错 error while loading shared libraries。
为什么加了 -L 和 -l 还提示找不到库
常见错误现象是编译成功，但运行时报 ./main: error while loading shared libraries: libmylib.so: cannot open shared object file: No such file or directory。这不是链接失败，而是**运行时加载失败**。
原因和解决建议如下：
-
-L只影响编译链接阶段，不影响运行时搜索路径 - 运行时默认只查
/lib、/usr/lib、/usr/local/lib等系统路径，不查你指定的./lib - 临时解决（开发调试）：
LD_LIBRARY_PATH=./lib ./main - 更可靠的做法：编译时用
-Wl,-rpath,./lib把运行时搜索路径硬编码进可执行文件：gcc main.c -L./lib -lmylib -Wl,-rpath,./lib -o main
gcc链接动态库时容易漏掉的关键参数
除了 -L 和 -l，以下参数在实际项目中常被忽略，但直接影响能否正确链接：
-
-fPIC：必须在**编译源码生成 .o 时加**，不是链接时加。没加会导致relocation R_X86_64_32 against `.rodata' can not be used when making a shared object -
-shared：用于生成.so，不是用于链接可执行文件；链接阶段不需要它 -
-Wl,--no-as-needed：某些 GCC 版本默认启用--as-needed，导致未显式调用的库被跳过；若依赖间接符号，可能需要此参数 -
-Wl,-soname,libmylib.so.1：生成.so时设置 soname，影响运行时匹配逻辑，对版本管理很重要
验证动态库是否真正被链接进可执行文件
别光看编译不报错就以为成了。运行前可用两个命令确认：
ldd ./main —— 查看可执行文件声明依赖哪些动态库，是否包含你的 libmylib.so（注意显示的是“not found”还是真实路径）
readelf -d ./main | grep NEEDED —— 直接看 ELF 动态段里记录的 NEEDED 条目，比 ldd 更底层、更可信
如果 ldd 显示 “not found”，但 readelf 里有对应条目，说明运行时路径配置有问题；如果 readelf 里压根没有，说明链接根本没生效——大概率是 -l 名字写错、或 -L 路径下实际没放对文件。
