-l和-l必须配对使用：-l指定库路径，-l指定库名（自动补lib前缀和.so后缀），且-l必须在-l之前；编译通过但运行时报“cannot open shared object file”，需用-wl,-rpath硬编码运行时路径或设置ld_library_path，并用ldd验证。
链接动态库时 -l 和 -L 必须配对使用
只写 -lmylib 而不指定路径，gcc 会去默认路径（如 /usr/lib、/lib）找 libmylib.so，找不到就报 cannot find -lmylib。这不是库不存在，而是路径没告诉链接器。
-
-L./lib告诉链接器：“去当前目录下的lib/里找库文件” -
-lmylib告诉链接器：“找名为libmylib.so的动态库”（自动补前缀lib和后缀.so） - 顺序不能颠倒：
-L必须出现在-l之前，否则无效 - 多个路径可用多个
-L，比如-L./lib -L/usr/local/lib
运行时报 “cannot open shared object file” 怎么办
编译通过但运行失败，典型错误是 ./a.out: error while loading shared libraries: libmylib.so: cannot open shared object file。说明链接器在编译时找到了库，但运行时动态加载器（ld.so）找不到它。
- 最直接办法：把
libmylib.so复制到系统库路径，如/usr/local/lib，再执行sudo ldconfig - 临时测试：用
export LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH把当前lib/加入运行时搜索路径 - 更可靠的方式：编译时用
-Wl,-rpath,./lib把路径硬编码进可执行文件，这样运行时不依赖环境变量 - 验证是否生效：运行
ldd ./a.out，看输出中libmylib.so是否已解析为绝对路径
同名静态库和动态库共存时，默认链接哪个
如果当前目录下同时有 libmylib.a 和 libmylib.so，且你只写了 -lmylib，gcc 默认优先链接 .so —— 这是链接器的固定行为，不是 bug。
- 想强制用静态库？加
-static参数：gcc main.c -L./lib -lmylib -static -o main（注意：这会使所有库都静态链接） - 只想对某一个库静态链接？绕过
-l，直接给 .a 文件路径：gcc main.c ./lib/libmylib.a -o main - 混合链接可行，但要注意顺序：目标文件在前，库文件（尤其是静态库）必须放在命令行靠后位置，否则符号可能无法解析
-fPIC 和 -shared 不是可选，是必须
生成动态库时漏掉 -fPIC 或 -shared，会导致严重问题：前者引发重定位错误（relocation R_X86_64_32 against `xxx' can not be used when making a shared object），后者则根本不会生成 .so 文件，而是一个普通可执行文件。
- 正确命令示例：
gcc -fPIC -shared -o libmylib.so mylib.o或gcc -fPIC -shared -o libmylib.so a.c b.c -
-fPIC必须加在所有参与编译的源或目标上；如果先生成.o，就得在gcc -c阶段加上 -
-shared只在最终生成.so时需要，链接可执行文件时不用它
-Wl,-rpath 和 ldd 验证这两步——很多人卡在“编译成功但运行失败”，却没意识到运行时路径和编译时路径是两套独立机制。
