gcc生成linux动态库必须同时使用-shared和-fpic：-shared指示链接器输出共享库，-fpic确保代码位置无关以支持多进程共享；缺一不可，否则将导致运行错误或生成非库文件。
gcc -shared -fPIC 是核心组合
生成 Linux 动态库（.so）必须同时用 -shared 和 -fPIC，缺一不可。前者告诉链接器输出共享库，后者确保代码能在任意内存地址加载——这是动态库能被多个进程共享的前提。
常见错误是漏掉 -fPIC：编译能过，但运行时报 cannot make segment writable for relocation 或直接段错误；只用 -fPIC 不加 -shared，则生成的是普通目标文件（.o），不是库。
-
gcc -fPIC -shared math.c -o libmath.so：单源文件，最简写法 -
gcc -fPIC -shared a.c b.c c.c -o libabc.so：多源文件直出，无需先编译.o -
gcc -fPIC -c a.c b.c; gcc -shared a.o b.o -o libab.so：分步编译，适合需要调试或复用目标文件的场景
为什么不能用 -c 单独生成 .so
-c 的作用是“只编译不链接”，它产出的是未解析符号的 .o 文件，而 .so 是已链接、带导出符号表的二进制文件。执行 gcc -c -shared foo.c -o libfoo.so 会报错：unrecognized command-line option '-shared'——因为 -c 和 -shared 语义冲突，GCC 不允许同时指定。
真正需要分步时，顺序只能是：
1. gcc -fPIC -c foo.c -o foo.o（生成位置无关目标文件）
2. gcc -shared foo.o -o libfoo.so（再链接成共享库）
libxxx.so 名字怎么定、要不要带版本号
名字本身没有强制约束，但惯例是前缀 lib + 名称 + .so，比如 libjson.so。链接时用 -ljson 就能自动匹配该名。
生产环境建议带版本号，例如 libjson.so.1.2.0，并创建软链接：ln -sf libjson.so.1.2.0 libjson.so.1ln -sf libjson.so.1 libjson.so
这样既支持运行时精确加载（SONAME 机制），又兼容旧链接命令（-ljson 找 libjson.so）。
注意：如果只写 gcc -shared ... -o libjson.so.1.2.0 而不建软链，ld 在链接阶段可能找不到 libjson.so，报 cannot find -ljson。
Windows 下 MinGW 编译 dll 要加 -Wl,--out-implib
MinGW 生成 .dll 时，若想让其他程序用 -lxxx 链接，必须额外生成导入库（.a 文件），否则链接失败。
正确命令是：gcc -fPIC -shared fun.c -o libfun.dll -Wl,--out-implib,libfun.dll.a
之后就能像 Linux 一样链接：gcc main.c -L. -lfun -o main.exe
没加 --out-implib 的话，虽然 libfun.dll 能运行，但链接阶段会提示 cannot find -lfun——因为 MinGW 默认不从 .dll 提取符号信息生成隐式导入库。
-fPIC 的必要性（尤其在 ARM 或较新 x86_64 系统上）、.so 文件名与 -l 参数的映射规则，以及 Windows 下导入库的显式生成要求。
