gcc生成动态库必须加-fpic，因为动态库加载地址不固定，需位置无关代码；不加会导致链接失败或运行时崩溃，-fpic使编译器生成通过got/plt间接寻址的代码，确保任意地址加载正常运行。
为什么GCC生成动态库必须加 -fPIC
因为动态库在加载时地址不确定，不加 -fPIC 会导致链接失败或运行时崩溃。
动态库（.so 文件）不是固定加载到某个内存地址的，而是由操作系统按需映射到进程的任意可用地址空间——这个过程叫“位置无关加载”（PIE 或 ASLR）。如果目标文件里包含绝对地址引用（比如跳转指令直接写死地址），加载器就无法安全重定位，轻则报错 relocation R_X86_64_32 against `.rodata' can not be used when making a shared object，重则程序启动即段错误。
-fPIC 的作用，就是让编译器生成只使用相对寻址、寄存器间接寻址的机器码，所有数据访问和函数调用都通过全局偏移表（GOT）和过程链接表（PLT）间接完成。这样，无论库被加载到哪，代码本身都不需要修改。
-fPIC 是编译阶段选项，不是链接阶段
很多人误以为只要链接时加 -shared 就够了，其实关键在编译目标文件时就要启用位置无关。
正确流程是两步分离：
- 先用
gcc -c -fPIC foo.c -o foo.o编译出位置无关的目标文件 - 再用
gcc -shared foo.o -o libfoo.so链接成动态库
如果漏掉 -fPIC 直接编译：gcc -c foo.c -o foo.o，哪怕后续加 -shared，链接器也会拒绝——因为它检测到目标文件含绝对重定位项。
注意：-fPIE 不行，它用于可执行文件；-fpic（小模型）在某些架构上可能不够用，-fPIC 是通用安全选择。
不加 -fPIC 的典型错误现象
常见报错信息直接指向问题根源：
relocation R_X86_64_32 against `.rodata' cannot be used when making a shared objectinvalid operation: non-PIE binary trying to link with shared library- 即使侥幸链接成功，运行时调用函数时出现
Segmentation fault (core dumped)
这些都不是环境配置问题，而是目标文件本身不具备位置无关性。尤其容易在以下场景踩坑：
- 用旧脚本直接把普通
.o文件打包进.so - 在 CMake 中忘记给
add_library(... SHARED)对应的源文件设置POSITION_INDEPENDENT_CODE ON - 混合使用不同编译选项的多个
.o文件（只要有一个没加-fPIC，整个.so就建不起来）
-fPIC 对性能和体积的影响很有限
有人担心加 -fPIC 会拖慢运行速度或增大体积，实际影响微乎其微。
现代 x86_64 和 ARM64 架构对 GOT/PLT 访问做了硬件优化，间接跳转开销几乎可忽略；生成的代码体积增加通常不到 1%。
真正要警惕的是反模式：
- 为省事在所有编译中无差别加
-fPIC（静态库、可执行文件不需要，徒增冗余） - 在嵌入式小资源平台（如某些 Cortex-M）上盲目启用，某些老编译器对
-fPIC支持不完善 - 误以为加了
-fPIC就能绕过符号冲突——它只解决地址重定位，不解决符号导出控制（还得靠-fvisibility=hidden等）
动态库构建里，-fPIC 是门槛级要求，不是可选项。漏掉它，后面所有步骤都白忙。
