Linux下生成动态库必须加-fPIC，否则运行时易报重定位错误或段错误；-shared需配合-fPIC使用，且链接时库参数须置于源文件之后。
gcc -shared 必须配合 -fPIC，否则链接失败
Linux 下用 gcc 生成动态库时，-fPIC 不是可选项，是硬性要求。没加它，gcc -shared 可能看似成功，但生成的 .so 文件在运行时大概率报 cannot make segment writable for relocation 或直接段错误。
原因很简单：动态库要被加载到任意内存地址，代码必须“位置无关”。而普通编译出的目标文件（.o）默认是位置相关的，-fPIC 才能生成符合要求的指令序列。
- 正确流程：
gcc -fPIC -c mylib.c -o mylib.o→gcc -shared -o libmylib.so mylib.o - 常见错误写法：
gcc -shared -o libmylib.so mylib.c（省略-fPIC，隐式编译不带该标志） - Windows（MinGW）下对应的是
-shared+-static-libgcc（避免依赖 MinGW 运行时 DLL），但-fPIC不强制；Linux 下缺它必挂
链接时 -l 参数顺序错，函数未定义引用
错误现象：明明 libmylib.so 存在、函数也定义了，但 gcc -L. -lmylib test.c -o test 却报 undefined reference to 'func_lib'。
根本原因不是库没找到，而是链接器处理顺序导致符号解析失败。链接器从左到右扫描参数，碰到 -lmylib 时，如果前面还没有未解决的符号（比如 test.c 还没读），它就认为“当前没需求”，直接跳过这个库。
- 错误命令：
gcc -o test -L. -lmylib test.c（库在源文件前） - 正确命令：
gcc -o test -L. test.c -lmylib（源文件或目标文件在前，库在后） - 更稳妥写法：把库放在所有依赖它的目标文件之后，例如
gcc -o test main.o util.o -L. -lmylib -lm
运行时报 cannot open shared object file，不是路径问题就是名字不对
编译通过、生成可执行文件也成功，但一运行就崩：./test: error while loading shared libraries: libmylib.so: cannot open shared object file: No such file or directory。
这通常不是 LD_LIBRARY_PATH 没设，而是两个更隐蔽的问题：
-
libmylib.so的 soname（内部名称）和文件名不一致。用readelf -d libmylib.so | grep SONAME查，如果显示libmylib.so.1，但你链接时用的是-lmylib，运行时就会找libmylib.so—— 名字对不上就找不到 - 你用
gcc -Wl,-soname,libmylib.so.1设了 soname，但没创建软链接：ln -sf libmylib.so.1 libmylib.so，导致链接阶段能过，运行时找不到基础名 -
LD_LIBRARY_PATH确实要设，但只对当前 shell 有效：export LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH"；系统级安装应放到/etc/ld.so.conf.d/并运行sudo ldconfig
头文件声明和实现不匹配，编译不报错但运行崩溃
函数在 mylib.h 里声明为 int func(int a, int b)，但 mylib.c 里实现成了 int func(float a, float b)，gcc 编译主程序时不会报错 —— 因为只看声明；但运行时栈帧错位，结果不可预测。
这类问题特别难定位，因为没有编译警告，甚至 nm libmylib.so | grep func 看起来也“存在”。
- 确保头文件和实现严格一致，尤其注意参数类型、
const、指针层级 - 建议开启
-Wall -Wextra，部分类型不匹配会在调用点触发警告（如传int*给期望const int*的函数） - 用
objdump -t libmylib.so | grep func对比符号类型，确认 ABI 层面是否真匹配
动态库的坑不在第一步怎么生成，而在“链接时谁先谁后”“运行时找谁”“声明和实现之间那层薄薄的信任”——这些地方一松动，程序就垮得无声无息。
