ar创建静态库必须显式使用-rcs参数，其中-s生成符号表以避免undefined reference；库名须为libXXX.a且与-lXXX严格匹配；链接时-L必须在-l之前。
ar命令创建静态库必须带 -r -c -s 三个参数
不加 -s 就算生成了 .a 文件，链接时大概率报 undefined reference —— 因为链接器找不到符号索引。现代 GNU ar 虽然在部分版本里把 -s 设为默认，但显式写出来才可靠。
正确写法是：ar rcs libfoo.a foo.o bar.o
-
r：替换或插入成员（遇到同名 .o 会覆盖） -
c：强制创建新归档（即使文件已存在也不报错） -
s：立即生成符号表（__.SYMDEF或 GNU 格式的全局索引），这是链接器能“按需提取”目标文件的前提
漏掉 -s 后用 nm libfoo.a 查不到符号，用 ld -verbose 看链接过程会发现它跳过了这个库。
静态库命名必须是 libXXX.a，且 XXX 是 -l 参数的值
比如你执行 gcc main.c -L. -lmyutil，链接器实际去找的是当前目录下的 libmyutil.a（或 libmyutil.so）。名字不匹配，哪怕文件就在那儿，也会报 cannot find -lmyutil。
常见错误：
- 写成
myutil.a→ 缺少lib前缀，-lmyutil找不到 - 写成
libmyutil.a.bak→ 多了后缀，链接器只认.a结尾 - 写成
libMyUtil.a但用-lmyutil→ 大小写敏感，Linux 下不匹配
验证是否命对名：运行 ls lib*.a，再对照 -l 后面的字符串去掉 lib 和 .a 剩下的部分。
链接时 -L 和 -l 的顺序不能乱，且自定义库必须放 -l 之前
这条命令是错的：gcc -o app main.c -lmyutil -L.
原因：GCC 按从左到右顺序解析参数，碰到 -lmyutil 时还没看到 -L.，于是去系统路径（如 /usr/lib）找，自然找不到。
正确顺序只有两种：
-
gcc -o app main.c -L. -lmyutil（推荐，清晰表达依赖） -
gcc -o app main.c libmyutil.a（绕过链接器搜索机制，直接喂文件）
注意：main.c 可以放在 -L. 和 -lmyutil 中间，GCC 允许；但绝不能放在 -lmyutil 后面，否则链接阶段会因未定义符号失败。
ar t / ar x 能快速验证静态库内容和结构
生成完 libfoo.a 后别急着链接，先确认里面真有你要的对象文件：
-
ar t libfoo.a→ 列出所有成员名，检查foo.o是否在其中 -
ar x libfoo.a foo.o→ 把指定成员解出来，可用file foo.o确认是 ELF relocatable -
nm -C libfoo.a | grep 'T hello'→ 查看是否有导出函数符号（T表示全局代码符号）
如果 ar t 输出为空，说明 ar 没成功写入，大概率是权限问题或路径写错；如果 nm 没输出，可能是源码没导出函数、编译时加了 -fvisibility=hidden，或 .o 本身就没定义该符号。
静态库不是“打包完就完事”，ar 的参数组合、命名规范、链接顺序这三处最容易卡住人，尤其是 -s 缺失导致的链接失败，现象隐蔽，容易误判成代码问题。
