ar 打包静态库本质是归档 .o 文件为 .a，不处理符号依赖或去重；正确命令为 ar rcs libname.a file1.o file2.o；须确保输入为已编译目标文件，非 .c/.h；链接时注意 -lfoo 对应 libfoo.a，-l 指定路径。
Linux下用 ar 打包静态库，本质是把多个 .o 文件归档成一个 .a 文件，不涉及编译或链接逻辑——它只是个“打包器”，不是“链接器”。别指望它自动解决符号依赖或去重。
ar rcs 是最安全的创建静态库命令
常见错误是只用 ar r，结果旧符号没被清除，新目标文件追加进去但旧版本仍残留，导致后续链接时行为异常（比如明明改了函数却还调用旧实现）。
-
ar r：仅替换已存在成员，不存在则新增；但不会删除已存在但未被替换的旧成员 -
ar rc：c表示“create if not exist”，但依然不清理无关旧成员 -
ar rcs：s会强制重新生成索引（__.SYMDEF），且实际中rcs组合已被广泛约定为“清空重建”语义（虽然ar本身无显式“delete”参数，但rcs配合从头传入目标列表，等效于覆盖）
正确写法：
ar rcs libfoo.a foo.o bar.o utils.o。注意顺序无关，
ar 不做符号解析，只是按序存档。
静态库必须包含 .o 文件，不能直接塞 .c 或 .h
有人试图 ar rcs libx.a main.c helper.h，结果链接时报 file format not recognized 或 undefined reference——因为 ar 只接受已编译的目标文件。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
.c文件需先用gcc -c编译：gcc -c -fPIC foo.c -o foo.o
（若用于共享库依赖，建议加-fPIC；静态库非必须，但统一风格更稳妥） -
.h文件对ar完全无意义，不应放入归档；头文件由使用者在编译时通过-I指定路径 - 检查归档内容用
ar -t libfoo.a，输出应全是*.o
链接时 -L 和 -l 的路径与命名规则容易错
写 gcc main.o -L. -lfoo -o app 却报 cannot find -lfoo，问题常出在命名和路径上：
-
-lfoo会让链接器搜索名为libfoo.a（或libfoo.so）的文件，不是foo.a或libfoo.o -
-L.表示在当前目录找，但若libfoo.a其实放在./libs/，就得写-L./libs - 可用
ld -verbose | grep SEARCH_DIR看默认搜索路径，避免误以为系统目录能自动命中
调试技巧：
gcc -Wl,--verbose main.o -L. -lfoo 2>&1 | grep "attempting file"，能看到链接器实际尝试打开哪些路径下的文件。
ar 本身不校验符号完整性，出错要靠后续链接阶段暴露
你可以用 ar rcs libbroken.a missing_symbol.o 成功执行，但只要 missing_symbol.o 里有未定义引用（如调用了 printf 却没连 libc），ar 完全不管——它只管打包二进制块。
- 真正发现问题是在
gcc main.o -L. -lbroken -o app这步，报undefined reference to 'printf' - 所以静态库构建后，建议用
nm -C libbroken.a | grep " U "查看是否存在未解析的全局符号（U表示 undefined） - 若确实需要自包含，得确保所有
.o已静态链接好依赖（例如用gcc -static-libgcc编译源文件），而非依赖ar解决
归档只是搬运工，别让它背链接的锅。
