用 gcc -fpic -shared 一次性编译多个 .c 文件是最简单可靠的方式，-fpic 保证代码位置无关，避免运行时报错；漏掉会导致 cannot load shared object 或段错误，且必须为每个源文件启用。
直接用 gcc -fPIC -shared 一次性编译多个 .c 文件是最简单、最不容易出错的方式，不需要手动管理中间 .o 文件。
为什么必须加 -fPIC
动态库在运行时可能被加载到任意内存地址，-fPIC（Position Independent Code）让生成的机器码不依赖固定地址。漏掉它，链接会成功，但运行时大概率报 cannot load shared object file 或直接段错误。
-
-fPIC必须出现在-shared前面或后面都行，但不能省 - 如果某个
.c里用了内联汇编或特殊寄存器操作，-fPIC可能导致编译失败，这时得检查该文件是否真适合做动态库 - 不是所有架构都默认支持
-fPIC（比如某些旧 ARM），交叉编译时要确认目标平台 ABI 要求
gcc -fPIC -shared 直接编译多个 .c 文件
这是推荐的入门做法，命令短、步骤少、出错路径少：
gcc -fPIC -shared src/utils.c src/math.c -Iinclude -o libmylib.so
-
src/utils.c和src/math.c会被依次预处理、编译、汇编，最后打包进一个.so -
-Iinclude让两个源文件都能找到include/下的头文件，不用各自写相对路径 - 所有全局函数（非
static）自动导出，无需额外声明__attribute__((visibility("default"))) - 如果某个
.c里定义了main()，会报错：动态库不允许有入口点，GCC 会提示multiple definition of 'main'
先编译成 .o 再合并（适合大型项目或需要单独调试）
当源文件多、编译时间长，或你想对某个模块单独加调试符号、优化等级时，分步更可控：
gcc -fPIC -c src/utils.c -Iinclude -o utils.o<br>gcc -fPIC -c src/math.c -Iinclude -o math.o<br>gcc -shared -o libmylib.so utils.o math.o
- 注意：
-fPIC只需在-c阶段加，-shared阶段不用重复 - 如果漏掉某个
.o的-fPIC，链接时会报relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object -
ar不能用于动态库——它只打包静态库；误用ar -rc libxxx.so xxx.o会产生无法加载的假.so文件
Makefile 中怎么组织多源文件动态库
实际工程中别手敲一长串 .c 名字，用变量和通配符更可靠：
CC = gcc<br>CFLAGS = -fPIC -Wall -Iinclude<br>LDFLAGS = -shared<br>SOURCES = $(wildcard src/*.c)<br>OBJECTS = $(SOURCES:.c=.o)<br>TARGET = libmylib.so<br><br>$(TARGET): $(OBJECTS)<br> $(CC) $(LDFLAGS) -o $@ $^<br><br>%.o: %.c<br> $(CC) $(CFLAGS) -c $<br>.PHONY: clean<br>clean:<br> rm -f $(OBJECTS) $(TARGET)
-
$(SOURCES:.c=.o)自动把所有src/xxx.c映射成src/xxx.o，不用硬编码列表 - 每个
.o编译命令隐含-fPIC，避免遗漏 - 如果某
.c文件依赖另一个模块的头文件，而那个模块还没编译，make会按依赖关系自动排序，比手敲命令安全
真正容易被忽略的是头文件路径一致性——-I 必须覆盖所有 #include 的查找范围，否则某个 .c 编译成功、另一个失败，错误信息往往只提示“xxx.h: No such file”，不会告诉你是在哪个源文件里出的问题。
