gcc/g++链接静态库时，-static不保证仅静态链接指定库，需用-wl,-bstatic/-wl,-bdynamic精确控制；必须确保libxxx.a命名规范、路径正确、符号导出且头文件独立配置。
直接用 -l 加库名、-L 指路径、-static 强制静态链接，但必须注意顺序和隐含规则——否则链接器会悄悄 fallback 到动态库。
gcc/g++ 链接静态库时为什么 -static 不一定生效
g++ 默认优先找 .so，即使你提供了 .a 文件，只要同名 .so 存在（哪怕没加 -L），它就可能被选中。加 -static 是全局开关，但它不保证“只链某个库”，而是让所有可静态链接的库都走静态路径——前提是对应 .a 真的存在且可找到。
-
-static会影响整个链接过程，包括libc、libstdc++等系统库，可能导致链接失败（比如某些系统库不提供完整静态版本） - 如果只想静态链接你自己的
libmyutil.a，而其他仍用动态，不能只靠-static，得配合-Wl,-Bstatic/-Wl,-Bdynamic控制粒度 -
libmyutil.a必须满足：名字符合libxxx.a格式；ar -t libmyutil.a能列出目标文件，说明不是空包或损坏
正确写法：-L、-l 和 -Wl,-Bstatic/-Bdynamic 组合
假设你的静态库是 libmyutil.a，放在当前目录，头文件在 ./include/，C++ 源文件是 main.cpp：
g++ -I./include main.cpp -L. -Wl,-Bstatic -lmyutil -Wl,-Bdynamic -o app
这里的关键点：
-
-L.告诉链接器去当前目录找库 -
-Wl,-Bstatic是把链接器选项-Bstatic透传给ld，让它接下来只找.a -
-lmyutil会被展开为libmyutil.a，且此时处于-Bstatic区间，所以强制选静态 -
-Wl,-Bdynamic立刻切回动态模式，避免后续系统库也被强行静态链接
常见错误现象和排查步骤
编译通过但运行时报 undefined symbol，或 ld: cannot find -lmyutil，大概率是路径或命名没对上：
- 检查
ls -l libmyutil.a是否真存在；名字拼错（比如写成libmyutil.a但用了-lmyutilx）会导致静默失败 - 运行
g++ -v ...（加完整命令）看输出里是否出现libmyutil.a的绝对路径；如果只看到libmyutil.so，说明-Bstatic没生效或库没被识别 - 用
nm -C libmyutil.a | grep YourFunctionName确认你要调用的函数确实导出了符号；C++ 函数名有 mangling，若头文件没加extern "C"，符号名会很长，容易匹配失败 - 静态库依赖其他静态库？比如
libmyutil.a内部调用了liblog.a，那必须把-llog放在-lmyutil后面，否则未解析符号不会回填
为什么不用 ar 直接打包进可执行文件
有人试过把 .o 文件直接丢进链接命令：g++ main.cpp util.o -o app。这能绕过库机制，但失去复用性——每次都要带一堆 .o，且无法做符号隔离或版本管理。真正需要静态库的场景（比如交付 SDK、嵌入式裁剪、CI 构建确定性），还是得走标准 ar + -l 流程。关键不是“能不能绕过”，而是“要不要维护契约”。
最易被忽略的一点：静态库本身不含头文件，#include 路径和 -I 必须独立配置；而且 C++ 模板实现通常不能放在 .a 里，得放头文件中，否则链接时找不到实例化代码。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
