为何Linux下静态库可依赖共享库？链接glog.a报unwind错误解析

“Linux环境下静态库无法依赖共享库”是与实际规则完全不符的错误认知。
Linux体系中的静态库（后缀.a）本质只是多个编译完成的目标文件（.o）的打包归档，从实现逻辑上就不存在符号自包含的强制要求：

• 静态库在打包归档阶段不会执行任何符号解析操作，也不会像动态库那样记录自身的依赖关系
• 它的唯一功能是在最终生成可执行文件的链接环节，被链接器按需抽取内部被引用的目标文件，合并到最终二进制中
• 静态库内部的目标文件只要存在对外部符号的引用，无论这些符号来自其他静态库还是共享库，都是完全合规的合法状态

你遇到的未定义引用报错中出现的_Ux86_64_getcontext、_ULx86_64_init_local、_ULx86_64_step等符号，全部是libunwind库提供的栈回溯接口。
发行版默认提供的预编译libglog.a，在编译时开启了栈回溯能力，且选择动态链接系统提供的libunwind.so，因此这个静态库文件本身就保留了对上述共享库符号的未解析引用。当你仅链接libglog.a和libgflags.a生成程序时，链接器找不到这些来自libunwind的符号，就会抛出对应的链接错误，手动追加-lunwind参数完成符号匹配即可解决问题。

“静态库不能依赖共享库”的说法广泛传播，本质是对编译规则的误解：

• 部分开发者在发布静态库时，会主动将所有依赖打包进静态库内部，实现开箱即用的体验，但这是人为选择的发布策略，不是系统层面的强制约束
• 静态库本身不存储依赖元数据，无法通过常规的依赖分析工具直接读取它的外部依赖列表，很容易让使用者误以为静态库是完全自包含的
• 主流Linux发行版出于磁盘空间利用率、ABI版本一致性的考量，默认编译所有静态库时都会优先动态链接系统级公共依赖（包括libunwind、libc、libstdc++等），避免将同一份代码重复打包到数十个静态库文件中造成冗余

内容的提问来源于stack exchange，提问作者Ke Yang