用g++生成libxxx.a静态库最简流程是：先g++ -c编译源码为.o文件，再用ar rcs打包为libxxx.a，最后ar -t验证内容；链接时需确保库顺序正确且符号未被修饰。
用 g++ 生成 libxxx.a 静态库最简流程
静态库本质就是归档（archive）多个 .o 目标文件，g++ 本身不直接生成 .a，得靠 ar。常见错误是试图用 g++ -shared 或 -fPIC——那是动态库的路子，静态库不需要。
实操分三步：
- 编译源码为对象文件：
g++ -c src/a.cpp src/b.cpp -o a.o b.o（注意-c，不链接） - 打包成静态库：
ar rcs libmylib.a a.o b.o（r插入、c创建、s生成索引） - 验证内容：
ar -t libmylib.a应列出所有.o文件
链接时找不到符号？检查 libxxx.a 的顺序和路径
g++ main.o -L. -lmylib -o app 看似正确，但链接器对静态库顺序敏感：被依赖的库必须放在依赖它的目标文件之后。如果 main.o 调用了 libmylib.a 中的函数，那 -lmylib 就得紧跟在 main.o 后面。
容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
-
-L.只影响后续-lxxx的查找，不改变已写死的绝对路径；若用g++ main.o /path/to/libmylib.a -o app，就完全绕过-L和-l -
libmylib.a必须导出 C++ 符号（非extern "C"封装），否则链接时看到的是_Z6myfuncv这类修饰名，而非myfunc - 若库中用了模板或内联函数，确保定义在头文件里——静态库只打包实现，不打包声明
Windows 下用 MSVC 生成 .lib 静态库的关键区别
MSVC 的 lib.exe 不是 GNU ar 的翻版：它不处理 C++ 名称修饰兼容性，也不自动生成符号索引。最常出错的是混用编译器 ABI（比如用 Clang 编译的 .obj 丢给 MSVC 的 lib.exe 打包）。
安全做法：
- 统一用
cl.exe编译：cl /c /EHsc a.cpp b.cpp→ 得到a.obj,b.obj - 用
lib.exe打包：lib a.obj b.obj /OUT:mylib.lib - 链接时注意运行时库匹配：若主程序用
/MT（静态链接 CRT），则静态库也得用/MT编译，否则出现LNK2005重复定义
静态库体积异常大？排查未裁剪的调试信息和未使用的代码
一个 10MB 的 libxxx.a 很可能塞满了调试符号（-g）或未优化的模板实例。GCC 默认不会 strip 静态库里的符号。
减小体积的实操点：
- 编译对象文件时加
-g0或干脆不加-g；若需调试，后期再用objcopy --strip-debug处理单个.o - 启用 LTO（Link Time Optimization）前先关掉：静态库阶段不支持
-flto，否则ar打包的是中间表示，链接时报undefined reference - 确认没把整个第三方头库（如 Boost）的实现全编译进去了——静态库只该含你自己写的、且明确需要发布的接口实现
真正麻烦的不是怎么生成，而是搞清哪些符号该暴露、哪些该隐藏，以及跨平台时 ABI 和运行时库的一致性——这些不写进构建脚本，光靠 ar 或 lib.exe 命令解决不了。
