必须加 -fpic，否则 gcc -shared 会静默失败或运行时崩溃；动态库代码必须位置无关，否则加载时无法正确寻址，现代 linux 的 ld 甚至直接拒绝链接非 pic 目标文件。
必须加 -fPIC，否则 gcc -shared 会静默失败或运行时崩溃
动态库代码必须是位置无关的，否则加载到不同进程地址空间时无法正确寻址。不加 -fPIC 编译出的 .so 文件可能通过链接，但运行时大概率报 Segmentation fault 或找不到符号。这不是警告，是硬性要求——现代 Linux 发行版（如 Ubuntu 22.04+、CentOS 8+）的 ld 甚至会直接拒绝链接非 PIC 目标文件。
常见错误现象：gcc -shared hello.o -o libhello.so 成功返回，但 ./app 运行时报错 cannot make segment writable for relocation，根源就是 hello.o 没有 -fPIC。
- 正确做法：先用
gcc -c -fPIC hello.c -o hello.o，再gcc -shared hello.o -o libhello.so - 偷懒写法（等效但不推荐用于多源文件）：
gcc -fPIC -shared hello.c -o libhello.so - 如果源文件含全局变量或
static函数，-fPIC仍必需；它影响的是所有数据和代码的寻址方式，不只是函数调用
gcc -shared 的输入可以是 .c 或 .o，但混合使用容易漏掉 -fPIC
直接传 .c 文件给 gcc -shared 时，GCC 会自动隐式加上 -fPIC（仅限该次编译），看起来省事。但一旦你有多个源文件，比如 mod_a.c 和 mod_b.c，用 gcc -shared mod_a.c mod_b.c -o libmod.so，GCC 只对这两个文件各自加 -fPIC 编译，没问题；可如果中间穿插了预编译的 .o（比如从静态库提取的），而那个 .o 是没加 -fPIC 编译的，链接就会失败或运行异常。
- 安全做法：统一先生成
-fPIC的.o，再gcc -shared链接，例如：gcc -c -fPIC mod_a.c mod_b.c→gcc -shared mod_a.o mod_b.o -o libmod.so - 不要混用：避免
gcc -shared mod_a.c mod_b.o -o libmod.so，除非你能 100% 确认mod_b.o是用-fPIC生成的 -
objdump -d mod_b.o | head可快速检查是否含call __x86.get_pc_thunk类指令，这是 PIC 的典型特征
链接时用 -L 和 -l，但运行时系统根本“看不见”这些参数
gcc main.c -L. -lhello -o app 能成功编译，不代表 ./app 就能运行。因为 -L 和 -l 只影响编译链接阶段，告诉链接器去哪找 libhello.so；运行时动态加载器（ld-linux.so）完全不读取这些参数，它只查：LD_LIBRARY_PATH、缓存文件 /etc/ld.so.cache（由 ldconfig 生成）、以及二进制中硬编码的 RPATH/RUNPATH。
- 临时解决：运行前执行
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH，然后./app - 永久解决（需 root）：把
libhello.so放到/usr/lib或/usr/local/lib，再运行sudo ldconfig - 推荐工程做法：编译时加
-Wl,-rpath,'$ORIGIN'，例如gcc main.c -L. -lhello -Wl,-rpath,'$ORIGIN' -o app，这样app会记录“在自己所在目录找库”，无需改环境变量
同名 .a 和 .so 共存时，gcc 默认优先选 .so，且无法用命令行强制绕过
当当前目录同时存在 libhello.a 和 libhello.so，执行 gcc main.c -L. -lhello -o app，GCC 总是链接 .so。这不是 bug，是设计行为——GNU ld 的默认策略就是 .so 优先于 .a。想强制用静态库？不能靠删 .so 或改顺序，得显式指定：
- 方法一：用
-static（全局静态链接，会影响所有库，慎用） - 方法二：用
-Wl,-Bstatic -lhello -Wl,-Bdynamic（只对hello生效） - 方法三：直接给出完整路径：
gcc main.c ./libhello.a -o app，绕过-l查找机制
最容易被忽略的一点：即使你用 -static 强制静态链接，如果 libhello.a 本身依赖其他动态库（比如用了 pthread），链接仍会失败，提示 undefined reference —— 因为静态库里的符号还是指向动态版本。真正干净的静态链接，需要所有依赖都提供静态版本并可用。
