“undefined reference”是链接阶段错误，因符号定义缺失所致，常见原因包括函数未定义、源文件未编译入链接、库未正确链接或ar缺-s参数导致索引缺失。
gcc -c 生成 .o 文件必须加 -c
不加 -c 会直接尝试链接，而你还没准备好主程序或入口函数，必然报错：undefined reference to `main'。静态库本质是多个 .o 文件的归档，不是可执行文件，所以每一步都得停在目标文件阶段。
常见错误是写成 gcc func.c -o libfunc.a，这根本不会生成静态库，而是试图链接一个没 main 的程序，直接失败。
-
gcc -c func.c -o func.o—— 正确：只编译，输出目标文件 -
gcc func.c -o func.o—— 错误：默认触发链接，报main缺失 - 多个源文件要分别编译成各自的
.o，再一起打包
ar rcs libxxx.a xxx.o 顺序不能反
ar 命令创建静态库时，rcs 三个标志位有固定含义：r 表示插入（replace），c 表示创建（create），s 表示生成索引（symbol table）。漏掉 s 会导致链接时找不到符号，报 undefined reference，但错误信息里完全不提 ar 问题，非常误导。
参数顺序必须是：ar rcs <code>libname.a file1.o file2.o。把 .o 放前面、.a 放后面会当作命令参数解析失败。
- 正确：
ar rcs libmath.a add.o sub.o - 错误：
ar rcs add.o sub.o libmath.a（ar报no output filename） - 漏
s：ar rc libmath.a *.o→ 链接时报错但看不出是索引缺失
Makefile 中静态库作为目标时依赖要写全
静态库本身是目标文件，但它的“新鲜度”取决于所有参与打包的 .o 文件。如果只写 libxxx.a: xxx.o，而实际有 xxx.o 和 yyy.o，那么改了 yyy.c 后 make 不会重新打包 libxxx.a，导致库中旧代码残留。
同时，.o 文件的依赖不能省略对应的 .c —— 否则改了源码也不会触发重新编译。
- 正确写法：
libmylib.a: a.o b.o<br> ar rcs $@ $^<br><br>a.o: a.c<br> gcc -c $<br>b.o: b.c<br> gcc -c $
- 错误写法：
libmylib.a: a.o（忽略b.o）、或a.o:（没写a.c依赖） -
$@是目标名，$^是全部依赖，用它们能避免硬编码重复
链接静态库时 -L 和 -l 顺序不能颠倒
用 gcc main.o -lmylib -L. 链接时，gcc 按从左到右顺序处理参数。如果 -lmylib 出现在 -L. 前面，gcc 就会在系统默认路径（如 /usr/lib）里找 libmylib.a，而不是当前目录，结果报 cannot find -lmylib。
静态库名必须带 lib 前缀和 .a 后缀，但 -l 参数只写中间部分；-L 指定的是目录，不是文件路径。
- 正确：
gcc main.o -L. -lmylib -o app - 错误：
gcc main.o -lmylib -L.（-l太早，路径没生效） - 错误：
gcc main.o -lmylib.a -L.（-l后不能带后缀） - 错误：
gcc main.o -L./libmylib.a -o app（-L后必须是目录）
ar 缺 s 标志、-l 和 -L 顺序颠倒、以及 Makefile 中漏掉某个 .o 的依赖声明——这三个地方出错，现象都是链接失败，但原因完全不同，排查时得一个个排除。
