gcc生成静态库必须分两步：先用gcc -c编译源文件为.o目标文件，再用ar rcs命令打包并生成符号索引（s不可省），形成libxxx.a；命名不规范或缺少索引将导致链接失败。
gcc 生成静态库必须分两步：先编译 .o，再用 ar 打包
静态库不是 gcc 直接“生成”的，gcc 只负责把源文件编译成目标文件（.o），真正打包成 .a 文件的是 ar 工具。跳过 .o 直接想用 gcc 输出 .a 会失败。
常见错误现象：gcc -static -o libfoo.a foo.c 看似合理，但实际生成的是可执行文件（名字碰巧叫 libfoo.a），不是静态库，链接时会报 file not recognized: file format not recognized。
- 第一步：用
gcc -c编译源码为.o文件gcc -c foo.c bar.c -o foo.o bar.o - 第二步：用
ar打包并生成符号索引ar rcs libfoo.a foo.o bar.o
其中r表示插入或替换，c表示创建新归档，s是关键——生成索引表，否则链接器可能找不到符号
ar rcs 命令里 s 参数不能省，否则链接可能失败
没有 s 参数的 ar rc libfoo.a foo.o bar.o 虽然能生成文件，但内部缺少符号索引（symbol table）。链接时若依赖顺序不对，或者库中多个 .o 含有互相引用的函数，ld 就无法定位目标文件，报错如：undefined reference to 'xxx'，即使函数明明在库里。
现代 ar 版本中 rcs 已成事实标准；不加 s 的情况多见于旧脚本或误抄文档。
- 验证索引是否存在：
ar -t libfoo.a能列出成员，但不够；更可靠的是nm -s libfoo.a | head -n 3，应看到符号列表 - 如果漏了
s，补救方式是运行ranlib libfoo.a（不过直接重跑ar rcs更稳妥）
静态库命名必须是 libxxx.a，-l 选项才认得
链接时写 -lfoo，gcc 会自动去找 libfoo.a 或 libfoo.so。如果你命名为 foo.a 或 libfoo_static.a，-lfoo 就完全无效，必须改用全路径链接：gcc main.c foo.a -o app。
这不是约定俗成，而是 ld 的硬编码行为：只按 lib{X}.a 模式搜索。
- 正确命名：
libmathutil.a→ 链接时可用-lmathutil - 错误命名：
mathutil.a、libmathutil_v1.a、mathutil.lib - 头文件和声明要匹配：库里的函数在
mathutil.h中声明，调用方#include "mathutil.h"，否则编译阶段就报错
链接静态库时，-L 和 -l 的顺序很关键
gcc 命令行从左到右解析，-lxxx 只对它**右侧**出现的库文件生效。写成 gcc -L. -lfoo main.c -o app 是错的——-lfoo 出现在 main.c 前，链接器此时还没看到任何未定义符号，不会去查库。
正确写法必须让 -lfoo 出现在所有源文件或目标文件之后：
- ✅
gcc main.c -L. -lfoo -o app - ✅
gcc main.o -L. -lfoo -o app - ✅
gcc main.c libfoo.a -o app（绕过 -L/-l，直接传 .a 文件） - ❌
gcc -L. -lfoo main.c -o app（常见手滑错误）
这个顺序问题在混合链接多个库（比如 -lfoo -lbar）时更明显：若 foo 依赖 bar，还必须写成 -lfoo -lbar，反过来会失败。
