静态库嵌套依赖与LNK2019链接错误的技术咨询

我正在开发名为A的项目，该项目会使用一款从源码编译的开源library B。我希望A.exe完全独立于libraryB及其所有依赖项，编译项目A时只需引入libraryB即可，无需处理其他子依赖。

libraryB已被编译为静态库*"libraryB.lib"*，我通过在CMakeLists.txt中添加target_link_libraries(libraryB)将其引入项目A。

编译项目A时出现LNK2019链接错误，提示libraryB中使用的符号BCryptOpenAlgorithmProvider未找到，该符号来自Win32的bcrypt.h。

我的疑问如下：

• 若libraryB编译为静态库，难道不应已包含所有依赖的必要源码？
• 将libraryB编译为动态.dll库能否消除项目A对bcrypt.h的依赖？
• 编译libraryB时无错误，是否需要在项目A的CMake配置中引入bcrypt库？这能否解决问题？

注：bcrypt.h及多数Win32函数已编译为.lib文件，我们无法获取其源码。我对静态库、动态库的交互逻辑存在困惑。

静态库与动态库核心逻辑先明确 #

静态库是目标文件的归档包，仅包含自身源码编译出的机器码，不会自动整合它依赖的外部库代码；编译静态库时，编译器只需要外部符号的声明（比如头文件里的函数原型）就能通过，依赖的链接检查会推迟到最终生成可执行文件的阶段。动态库则是独立的可执行模块，编译时会完成自身依赖的链接，最终可执行文件只需要链接动态库的导入库，运行时加载动态库即可。

针对疑问的具体解答 #

1. 静态库不会包含所有依赖的必要源码
   静态库只打包自身的编译产物，对于它依赖的系统库、第三方库，只会保留对这些库中符号的引用，不会把依赖的代码打包进去。比如BCryptOpenAlgorithmProvider是Windows系统库bcrypt提供的函数，其实现不在libraryB的源码里，所以libraryB.lib中不会有这部分代码，只是记录了需要调用这个函数的信息。

2. 编译为动态库能转移编译阶段的依赖，但无法完全消除运行时依赖
   如果把libraryB编译为.dll，那么链接bcrypt.lib的步骤会在编译libraryB.dll时完成，此时生成的.dll会依赖系统的bcrypt.dll。这种情况下，编译A.exe时只需要链接libraryB的导入库（libraryB.lib），不需要再处理bcrypt的编译阶段依赖——但A.exe运行时仍然需要libraryB.dll和系统的bcrypt.dll存在。这只是把编译阶段的依赖转移到了运行阶段，并不能让A.exe完全独立。

3. 在项目A的CMake中引入bcrypt库可以解决当前链接错误
   是的，你需要在项目A的CMake配置中显式链接bcrypt库。Windows系统提供的bcrypt对应的导入库是bcrypt.lib，修改你的CMakeLists.txt：

target_link_libraries(A PRIVATE libraryB bcrypt)

这样编译A.exe时，链接器会找到BCryptOpenAlgorithmProvider的实现，从而解决LNK2019错误。

额外建议 #

如果希望A.exe尽可能独立，静态链接是更合适的选择，但需要确保所有依赖（包括系统库的静态版本）都被正确链接。部分Windows系统库同时提供静态版和动态版，比如bcrypt的静态库通常为bcrypt_static.lib，若要完全静态链接，可以尝试使用这个版本，但需注意系统库的许可和兼容性问题。

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