动态库必须使用-fPIC编译生成位置无关代码，否则链接时报错“relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object”，因.so加载需支持任意内存地址，而-fPIC通过GOT/PLT实现相对寻址；静态库无需-fPIC，主程序一般也不需，除非启用ASLR（此时用-fPIE）。
动态库必须位置无关：否则加载会失败
动态库（.so）在运行时可能被加载到任意内存地址，而普通编译生成的代码默认使用绝对地址寻址。如果动态库里有硬编码的地址，加载器就无法把它搬到别的地方——直接报错或崩溃。-fPIC的作用就是让编译器生成“位置无关代码”（Position Independent Code），所有跳转、函数调用、全局变量访问都通过相对偏移或GOT/PLT间接完成，不依赖固定基址。
不加-fPIC编译.so文件会报什么错
常见错误是链接阶段直接失败，提示类似：
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
这是因为链接器ld在构建.so时强制要求所有输入目标文件（.o）必须是PIC格式。即使你只写了一个.c文件，也要先用gcc -fPIC -c foo.c生成.o，再用gcc -shared -o libfoo.so foo.o链接。
-
-fPIC是编译选项，必须加在gcc -c这一步，不能只加在-shared链接时 - 某些旧架构（如i386）还有
-fpic（小范围PIC），但x86_64一律用-fPIC - 静态库（
.a）不需要-fPIC；只有.so和要被.so引用的目标文件才需要
加了-fPIC有什么代价
主要影响两点：代码体积略大、少量性能开销。
- 每次访问全局变量或调用外部函数，都要多一次间接寻址（查GOT或PLT），比直接地址访问慢一两个周期
- 生成的
.o文件比非PIC版本大约5%–10%，但对最终.so大小影响不大 - 现代CPU分支预测和缓存能很好掩盖这部分开销，实际业务代码中几乎不可测
所以只要你在编译动态库，-fPIC不是可选项，是必选项——漏掉它，连.so都出不来。
为什么主程序一般不用-fPIC
主程序（可执行文件）由链接器分配固定虚拟地址（如0x400000），所有符号地址在链接时就能确定，不需要运行时重定位。除非你要把主程序也做成DSO（比如用dlopen(NULL, ...)加载自身），否则加-fPIC纯属多余，还拖慢编译。
但注意：-fPIE（位置无关可执行文件）是另一回事，用于启用ASLR安全机制，和-fPIC目的不同，不要混淆。
