简介这是一份由VC2015Visual C 2015编译的libssh 0.10.3静态库资源专供Windows平台C/C开发者在本机项目中快速集成SSH协议能力。libssh支持SSH1/SSH2提供远程登录、安全文件传输等底层接口静态库免去了运行时依赖配置适合需要独立分发或编译集成的中高级开发者使用。压缩包共10个文件以7个头文件h/hpp和2个.lib静态库文件为主分别对应声明与链接入口整体仅636KB轻量易用。目前已有174人学习下载。库包按debug/release分别组织并附有vc140运行库相关说明便于在Visual Studio中配置头文件路径、字符集与链接器输入同时描述中还涉及项目配置、错误处理、日志排查与安全更新等实用要点能帮助读者减少移植和编译过程中的踩坑成本。 前阵子接了个老项目的维护活开发机清一色vc2015要在现有工程里加一个SSH远程文件传输功能。技术选型时我几乎没犹豫就锁定了libssh这个开源库但很快遇到第一个硬骨头libssh官方只发布源码包Windows上没有现成的二进制我需要用vc2015手动把libssh-0.10.3编成一份静态库。于是就有了这篇文章里这一整套折腾记录。内容会从为什么选静态库开始一直讲到这份静态库编译完怎么正确链接进工程。全程只围绕一件事怎么在vc2015的约束下把libssh-0.10.3静态库从源码变成能用的.lib文件以及链接阶段有哪些坑。老项目维护的同学、需要在Windows下集成SSH/SFTP功能的C/C开发者这份笔记应该都能直接抄作业。1. 为什么盯上libssh静态库需求来源与方案选型先交代一下背景。我这个老项目是Windows客户端运行环境常年不更新部署方式也是传统的一包走天下。客户机器上装一堆DLL这种事领导不答应客户也不答应所以从一开始我选型的方向就是静态库。1.1 动态库和静态库这次我选了静态libssh在Windows平台有两种使用形态一种是编译成libssh.dll动态库使用时exe旁边带着dll另一种是编译成libssh_static.lib静态库链接时把代码直接揉进exe。我经常用冰箱和外卖来打比方动态库像外卖小哥dll得在饭点准时出现不在就吃不上饭静态库像自家冰箱里的冻饺子材料都在家什么时候想吃直接煮就行。二者没有绝对的好坏但放到我这个项目里静态库的优势非常明显。对比维度静态库动态库部署方式一个exe就能跑exe旁边必须带一堆dll版本一致性编译时就锁定不怕环境变化客户机器上可能出现dll版本冲突安全软件兼容无额外dll加载不容易被误拦新增dll容易被安全软件重点审查主程序体积变大一般可接受保持较小但库文件要跟着分发升级维护库有改动必须重新编译整个程序替换dll就能更新函数实现从实际部署看老项目客户环境杂有的机器连VC运行库都不一定全。静态库把libssh和依赖都揉进exe运行环境干净很多。我之前做过一个项目就是被dll版本冲突坑惨了所以这次宁可exe大几百KB也要把带不带一堆外部文件这个变量彻底干掉。1.2 为什么是VC2015和0.10.3的搭配很多朋友第一反应是都用2024年了为什么还守着vc2015原因很简单项目工具链一旦定下来就不太敢动。客户现场、老代码依赖、第三方商业库的授权都绑定在VS2015上。与其冒险升级整个工具链不如在这个约束下把libssh编译出来。MSVC编译器对C库的二进制兼容性有严格边界VS2015生成的静态库放进VS2015工程里链接是最稳的组合不会有LNK2038这类运行库不匹配的问题。版本选0.10.3是因为它是0.10系列里比较新的稳定版修复了一堆安全问题对新版OpenSSL 1.1.1支持也好。SSH这个领域最怕的就是安全漏洞既然要集成就选一个还在维护分支内的版本别去碰那些已经很老但网上教程特别多的古董版本后面加密算法落后、协议兼容性出问题都是麻烦。2. 编译前的准备工具链与依赖补齐libssh本身用CMake构建但Windows下编译它绕不开一个前置依赖OpenSSL。很多人卡就卡在这一步前面工具没备齐后面全是连锁反应。2.1 需要准备的工具和版本建议工具版本建议说明Visual Studio 2015Update 3必须安装C桌面开发相关组件Update 3对C99支持更好CMake3.16以上到官网下载zip版即可记得加入PATHPerlStrawberry Perl 5.3xOpenSSL构建脚本依赖Perl安装后确认perl能执行NASM2.15以上如果OpenSSL启用汇编优化需要它用no-asm可以跳过OpenSSL源码1.1.1系列比如openssl-1.1.1w稳定且libssh兼容性好这里把OpenSSL单独拿出来强调一下。libssh本身不实现加密算法它把AES、RSA、ECDH这些基础密码学运算外包给了OpenSSL。可以理解成libssh负责整车组装发动机是向OpenSSL采购的。所以编译libssh之前必须先把OpenSSL静态库编出来否则CMake配置阶段就会直接报找不到OpenSSL。2.2 OpenSSL静态库绕不过去的前置依赖编译OpenSSL的步骤相对机械但有几个选择会直接影响后面libssh的使用。打开VS2015 x64 Native Tools Command Prompt解压OpenSSL源码后进入目录执行下面的命令perl Configure VC-WIN64A no-asm no-shared --prefixD:/openssl-1.1.1w-build nmake nmake install_sw这里两个参数我有意做了选择。no-asm是关闭汇编优化这样省去了NASM的安装和路径配置编译速度虽然慢一点但省掉一个最容易出问题的环节。其实日常内部工具对那百分之十几的性能损失感知不强稳定省心更重要。no-shared则是让OpenSSL只产出静态库这样最终exe不会在运行时还需要额外的OpenSSL dll。install_sw只安装软件部分不装文档省时间。需要特别注意位数的匹配。如果你最终工程是64位OpenSSL必须用VC-WIN64A配置如果是32位就用VC-WIN32。这个架构选择必须和libssh以及最终exe完全一致混搭会在CMake检测或者链接阶段出现各种莫名其妙的问题。这步编完后D:/openssl-1.1.1w-build下面应该有include和lib两个目录libcrypto.lib和libssl.lib都在lib里后面CMake配置要指到这里。3. CMake配置与静态库生成工具链和依赖就绪后真正编译libssh本身反而比较快重点是CMake参数别配错。3.1 CMake参数与配置命令详解我建议命令行操作不推荐CMake GUI。命令行可重复、可记录出了问题看输出也清晰。新建一个build目录在源码目录下配置cmake .. -G Visual Studio 14 2015 Win64 ^ -DWITH_STATIC_LIBON ^ -DWITH_SHARED_LIBOFF ^ -DBUILD_SHARED_LIBSOFF ^ -DWITH_SERVEROFF ^ -DWITH_SSH1OFF ^ -DWITH_ZLIBOFF ^ -DOPENSSL_ROOT_DIRD:/openssl-1.1.1w-build ^ -DOPENSSL_INCLUDE_DIRD:/openssl-1.1.1w-build/include ^ -DOPENSSL_CRYPTO_LIBRARYD:/openssl-1.1.1w-build/lib/libcrypto.lib ^ -DOPENSSL_SSL_LIBRARYD:/openssl-1.1.1w-build/lib/libssl.lib ^ -DCMAKE_INSTALL_PREFIXD:/libssh-0.10.3-installWindows命令行里用^做续行符如果是在PowerShell下操作把^换成反引号。各个参数拆开看WITH_STATIC_LIBON和WITH_SHARED_LIBOFF这是libssh自己的编译开关明确告诉它只产出静态库。顺手再给一个BUILD_SHARED_LIBSOFF是为了兼容CMake的习惯三个开关一起确保CMake不会默认生成dll。WITH_SERVEROFF我这个项目只需要SSH客户端功能不需要服务端关掉能少编译一部分代码生成的库也更小。WITH_SSH1OFFSSH1协议早就淘汰了开着只会增加安全面和代码量。WITH_ZLIBOFF关掉压缩支持。如果不关CMake会去找zlib库又得多编一个依赖。SSH传输本身的压缩在绝大多数局域网和内部工具场景下收益不大关掉能降低不少复杂度。OpenSSL的三个路径参数直接告诉CMake去哪找OpenSSL的头文件和库文件。只给ROOT_DIR有时候不够把CRYPTO和SSL的库文件路径也显式指出来能少折腾一轮检测。这里有个我踩过的大坑如果之前用CMake GUI配过别的路径或者配置失败过里面有残留的CMakeCache.txt一定要删掉重来。缓存会把之前错误的OpenSSL路径、错误的Generator类型都记住然后一遍遍给你报同一个错极其容易让人上头。我后来习惯是每个版本独立一个build目录配置失败直接删目录重来。3.2 编译与产物确认配置成功后编译和安装一步到位cmake --build . --config Release --target install --parallel 8--parallel 8是8线程并行编译机器够好的话能快不少。编译完成后去D:/libssh-0.10.3-install看产物正常情况下有include/ libssh/ libssh.h libssh_version.h sftp.h ... lib/ libssh_static.lib libssh.lib # 有些版本会同时生成一个别名或导入库确认静态库是否生成最简单的方法是看文件大小。libssh_static.lib通常有几百KB甚至更大而动态库对应的导入库才几十KB。用VS自带的dumpbin工具也可以查dumpbin /headers D:/libssh-0.10.3-install/lib/libssh_static.lib输出里如果显示的是静态库特征没有DLL相关的描述信息那就没问题。编译日志建议留一份后面如果链接出问题回头翻日志能确认当时的编译配置到底是什么状态。4. 静态库的链接使用真正容易踩坑的地方编译成功只是第一步把静态库正确链接进工程才是真正检验功课的地方。这个阶段踩坑的人最多因为涉及IDE工程配置和库依赖关系。4.1 使用静态库必须做的三件事在VS2015工程里使用这份静态库有三件事缺一不可。第一件配置头文件路径。在项目属性里把D:/libssh-0.10.3-install/include加到C/C常规附加包含目录。第二件定义LIBSSH_STATIC宏。这是libssh头文件里的一个编译开关。看源码就知道libssh.h里根据LIBSSH_STATIC是否定义来决定LIBSSH_API是空还是__declspec(dllimport)。不定义这个宏头文件会默认把API声明成从dll导入链接时就会报一堆LNK2019。这个宏要在预处理器定义里加LIBSSH_STATIC第三件把依赖库全部加到链接器附加依赖项。这里不能只加libssh_static.lib它依赖的OpenSSL库和Windows系统库也要一并加上。我这边实际可用的最小集合是libssh_static.lib libssl.lib libcrypto.lib crypt32.lib ws2_32.lib advapi32.lib user32.libws2_32.lib是Windows sockets实现SSH通信底层离不开socketcrypt32.lib和advapi32.lib提供证书和加密相关APIuser32.lib在外层链接时偶尔会被用到加上不影响什么。链接顺序上建议libssh和OpenSSL的库放前面系统库放后面可以减少一部分符号解析顺序问题。代码层面和普通用法一样#include libssh/libssh.h #include libssh/sftp.h只要上面的配置都到位编译链接就能过。我在这一步卡过一整个下午最后发现就是漏了LIBSSH_STATIC宏链接器报的一堆unresolved external symbol瞬间全消失。4.2 运行库模式不一致引发的链式报错VS编译时有个运行库设置在工程属性的C/C代码生成里Release默认是/MD也就是动态链接到C运行时库/MT则是把C运行时静态链接进来。这个设置和libssh编译时的运行库模式必须保持一致否则链接阶段会出现经典的LNK2038错误。这个LNK2038报错信息里会明确写RuntimeLibrary mismatch还有_ITERATOR_DEBUG_LEVEL不匹配之类的提示。Debug和Release混用、/MD和/MT混用都会触发。这里的逻辑就是每个库都按自己当时的配置链了对应的C运行时两个库的行李不一致链接器自然不认账。解决方案有两个方向。第一个是把整个工程的运行库设置成和libssh一致如果你没有其他历史包袱CMake默认编出来的libssh静态库在Release下是/MD那你工程Release也保持/MD即可。第二个是如果项目里其他静态库要求/MT那么libssh也要用/MT重新编一份这时CMake配置需要加一个参数cmake .. -DCMAKE_MSVC_RUNTIME_LIBRARYMultiThreaded我个人的习惯是编译第三方库前先想清楚最终要对接什么样的工程配置然后固定下来所有库统一跑同一个运行库模式。最怕的是A库/MD、B库/MT、本项目/MT这种混搭状态下链接错误会变得极其难排查。5. 常见问题与排查技巧实录这节整理我在编译和对接过程中遇到过的实际问题基本都是搜索了很多资料、反复试验才解决的。为了方便查阅我用表格列出来后面再补充一些更具体的排查思路。5.1 编译阶段的典型问题现象可能原因排查与解决CMake报Could NOT find OpenSSLOPENSSL_ROOT_DIR没设置或OpenSSL还没编检查OpenSSL是否已用nmake install_sw安装并显式指定ROOT_DIR和两个LIBRARY路径CMake报Could NOT find PerlPerl没装或不在PATH安装Strawberry Perl并确认perl -v能正常执行CMake报Could NOT find NASM编译OpenSSL时带了汇编优化但没装NASM如果在libssh阶段遇到检查OpenSSL编译时的配置用no-asm可跳过这个依赖编译中报无法打开libcrypto.libOpenSSL库文件不存在或位数与当前工程不匹配确认x64项目对应VC-WIN64Awin32对应VC-WIN32且lib目录下有libcrypto.lib编译报C99语法不支持VS2015对部分C99特性支持不完整升级到VS2015 Update 3当前libssh官方源码一般不会有这个问题这里有一个比较隐蔽的坑是CMake缓存。第一次配置失败后问题修改好了再执行cmake它并不会重新检测所有变量而是基于缓存里已记录的选项继续。我见过很多人在OpenSSL路径写错之后反复改路径参数始终报同一个错最后把build目录整个删掉重新配置就通过了。所以在编译阶段凡是遇到我明明改对了还报错的情况优先怀疑缓存。5.2 链接与运行阶段的问题现象可能原因排查与解决LNK2019 unresolved external symbol ssh_new 等LIBSSH_STATIC宏没定义或libssh_static.lib没加到链接器预处理器定义加LIBSSH_STATIC检查附加依赖项里是否有libssh_static.libLNK2038 RuntimeLibrary mismatch运行库模式不一致/MD和/MT混用统一工程和库的运行库设置必要时用CMAKE_MSVC_RUNTIME_LIBRARY重新编译LNK2019 unresolved ... crypt32/ws2_32缺少Windows系统库在附加依赖项里补上crypt32.lib、ws2_32.lib、advapi32.lib、user32.libLNK2019 unresolved ... EVP_xxx 等OpenSSL符号OpenSSL库没链接或版本不对附加依赖项确认有libssl.lib和libcrypto.lib且路径指向之前编译成功的目录程序运行起来就崩溃和跨模块内存分配释放不一致有关静态库场景下重点是运行库统一同时确认没有混用Debug版库和Release版库链接阶段的错误信息往往很长别被一大串undymbol吓到核心是看第一个报错符号属于谁。比如第一个未解析符号是ssh_new那问题大概率在libssh静态库本身或者LIBSSH_STATIC宏如果第一个符号是EVP_aes_128_cbc那是OpenSSL没链进去比库顺序和依赖问题更常见。前前后后编译过不下三回最大体会就一句话Windows上编译第三方C库最折腾的不是编译本身而是把依赖关系、运行库、位数这些看不见的约束提前想清楚。我到现在还留着当时的CMake配置命令和OpenSSL编译脚本隔了两个月再重编同一套东西翻出来照着跑一遍就能出库。老项目的维护就是这样一次折腾清楚后面全是省心活。本文还有配套的精品资源点击获取 VC2015编译libssh静态库指南：从源码到链接的完整实操
简介这是一份由VC2015Visual C 2015编译的libssh 0.10.3静态库资源专供Windows平台C/C开发者在本机项目中快速集成SSH协议能力。libssh支持SSH1/SSH2提供远程登录、安全文件传输等底层接口静态库免去了运行时依赖配置适合需要独立分发或编译集成的中高级开发者使用。压缩包共10个文件以7个头文件h/hpp和2个.lib静态库文件为主分别对应声明与链接入口整体仅636KB轻量易用。目前已有174人学习下载。库包按debug/release分别组织并附有vc140运行库相关说明便于在Visual Studio中配置头文件路径、字符集与链接器输入同时描述中还涉及项目配置、错误处理、日志排查与安全更新等实用要点能帮助读者减少移植和编译过程中的踩坑成本。 前阵子接了个老项目的维护活开发机清一色vc2015要在现有工程里加一个SSH远程文件传输功能。技术选型时我几乎没犹豫就锁定了libssh这个开源库但很快遇到第一个硬骨头libssh官方只发布源码包Windows上没有现成的二进制我需要用vc2015手动把libssh-0.10.3编成一份静态库。于是就有了这篇文章里这一整套折腾记录。内容会从为什么选静态库开始一直讲到这份静态库编译完怎么正确链接进工程。全程只围绕一件事怎么在vc2015的约束下把libssh-0.10.3静态库从源码变成能用的.lib文件以及链接阶段有哪些坑。老项目维护的同学、需要在Windows下集成SSH/SFTP功能的C/C开发者这份笔记应该都能直接抄作业。1. 为什么盯上libssh静态库需求来源与方案选型先交代一下背景。我这个老项目是Windows客户端运行环境常年不更新部署方式也是传统的一包走天下。客户机器上装一堆DLL这种事领导不答应客户也不答应所以从一开始我选型的方向就是静态库。1.1 动态库和静态库这次我选了静态libssh在Windows平台有两种使用形态一种是编译成libssh.dll动态库使用时exe旁边带着dll另一种是编译成libssh_static.lib静态库链接时把代码直接揉进exe。我经常用冰箱和外卖来打比方动态库像外卖小哥dll得在饭点准时出现不在就吃不上饭静态库像自家冰箱里的冻饺子材料都在家什么时候想吃直接煮就行。二者没有绝对的好坏但放到我这个项目里静态库的优势非常明显。对比维度静态库动态库部署方式一个exe就能跑exe旁边必须带一堆dll版本一致性编译时就锁定不怕环境变化客户机器上可能出现dll版本冲突安全软件兼容无额外dll加载不容易被误拦新增dll容易被安全软件重点审查主程序体积变大一般可接受保持较小但库文件要跟着分发升级维护库有改动必须重新编译整个程序替换dll就能更新函数实现从实际部署看老项目客户环境杂有的机器连VC运行库都不一定全。静态库把libssh和依赖都揉进exe运行环境干净很多。我之前做过一个项目就是被dll版本冲突坑惨了所以这次宁可exe大几百KB也要把带不带一堆外部文件这个变量彻底干掉。1.2 为什么是VC2015和0.10.3的搭配很多朋友第一反应是都用2024年了为什么还守着vc2015原因很简单项目工具链一旦定下来就不太敢动。客户现场、老代码依赖、第三方商业库的授权都绑定在VS2015上。与其冒险升级整个工具链不如在这个约束下把libssh编译出来。MSVC编译器对C库的二进制兼容性有严格边界VS2015生成的静态库放进VS2015工程里链接是最稳的组合不会有LNK2038这类运行库不匹配的问题。版本选0.10.3是因为它是0.10系列里比较新的稳定版修复了一堆安全问题对新版OpenSSL 1.1.1支持也好。SSH这个领域最怕的就是安全漏洞既然要集成就选一个还在维护分支内的版本别去碰那些已经很老但网上教程特别多的古董版本后面加密算法落后、协议兼容性出问题都是麻烦。2. 编译前的准备工具链与依赖补齐libssh本身用CMake构建但Windows下编译它绕不开一个前置依赖OpenSSL。很多人卡就卡在这一步前面工具没备齐后面全是连锁反应。2.1 需要准备的工具和版本建议工具版本建议说明Visual Studio 2015Update 3必须安装C桌面开发相关组件Update 3对C99支持更好CMake3.16以上到官网下载zip版即可记得加入PATHPerlStrawberry Perl 5.3xOpenSSL构建脚本依赖Perl安装后确认perl能执行NASM2.15以上如果OpenSSL启用汇编优化需要它用no-asm可以跳过OpenSSL源码1.1.1系列比如openssl-1.1.1w稳定且libssh兼容性好这里把OpenSSL单独拿出来强调一下。libssh本身不实现加密算法它把AES、RSA、ECDH这些基础密码学运算外包给了OpenSSL。可以理解成libssh负责整车组装发动机是向OpenSSL采购的。所以编译libssh之前必须先把OpenSSL静态库编出来否则CMake配置阶段就会直接报找不到OpenSSL。2.2 OpenSSL静态库绕不过去的前置依赖编译OpenSSL的步骤相对机械但有几个选择会直接影响后面libssh的使用。打开VS2015 x64 Native Tools Command Prompt解压OpenSSL源码后进入目录执行下面的命令perl Configure VC-WIN64A no-asm no-shared --prefixD:/openssl-1.1.1w-build nmake nmake install_sw这里两个参数我有意做了选择。no-asm是关闭汇编优化这样省去了NASM的安装和路径配置编译速度虽然慢一点但省掉一个最容易出问题的环节。其实日常内部工具对那百分之十几的性能损失感知不强稳定省心更重要。no-shared则是让OpenSSL只产出静态库这样最终exe不会在运行时还需要额外的OpenSSL dll。install_sw只安装软件部分不装文档省时间。需要特别注意位数的匹配。如果你最终工程是64位OpenSSL必须用VC-WIN64A配置如果是32位就用VC-WIN32。这个架构选择必须和libssh以及最终exe完全一致混搭会在CMake检测或者链接阶段出现各种莫名其妙的问题。这步编完后D:/openssl-1.1.1w-build下面应该有include和lib两个目录libcrypto.lib和libssl.lib都在lib里后面CMake配置要指到这里。3. CMake配置与静态库生成工具链和依赖就绪后真正编译libssh本身反而比较快重点是CMake参数别配错。3.1 CMake参数与配置命令详解我建议命令行操作不推荐CMake GUI。命令行可重复、可记录出了问题看输出也清晰。新建一个build目录在源码目录下配置cmake .. -G Visual Studio 14 2015 Win64 ^ -DWITH_STATIC_LIBON ^ -DWITH_SHARED_LIBOFF ^ -DBUILD_SHARED_LIBSOFF ^ -DWITH_SERVEROFF ^ -DWITH_SSH1OFF ^ -DWITH_ZLIBOFF ^ -DOPENSSL_ROOT_DIRD:/openssl-1.1.1w-build ^ -DOPENSSL_INCLUDE_DIRD:/openssl-1.1.1w-build/include ^ -DOPENSSL_CRYPTO_LIBRARYD:/openssl-1.1.1w-build/lib/libcrypto.lib ^ -DOPENSSL_SSL_LIBRARYD:/openssl-1.1.1w-build/lib/libssl.lib ^ -DCMAKE_INSTALL_PREFIXD:/libssh-0.10.3-installWindows命令行里用^做续行符如果是在PowerShell下操作把^换成反引号。各个参数拆开看WITH_STATIC_LIBON和WITH_SHARED_LIBOFF这是libssh自己的编译开关明确告诉它只产出静态库。顺手再给一个BUILD_SHARED_LIBSOFF是为了兼容CMake的习惯三个开关一起确保CMake不会默认生成dll。WITH_SERVEROFF我这个项目只需要SSH客户端功能不需要服务端关掉能少编译一部分代码生成的库也更小。WITH_SSH1OFFSSH1协议早就淘汰了开着只会增加安全面和代码量。WITH_ZLIBOFF关掉压缩支持。如果不关CMake会去找zlib库又得多编一个依赖。SSH传输本身的压缩在绝大多数局域网和内部工具场景下收益不大关掉能降低不少复杂度。OpenSSL的三个路径参数直接告诉CMake去哪找OpenSSL的头文件和库文件。只给ROOT_DIR有时候不够把CRYPTO和SSL的库文件路径也显式指出来能少折腾一轮检测。这里有个我踩过的大坑如果之前用CMake GUI配过别的路径或者配置失败过里面有残留的CMakeCache.txt一定要删掉重来。缓存会把之前错误的OpenSSL路径、错误的Generator类型都记住然后一遍遍给你报同一个错极其容易让人上头。我后来习惯是每个版本独立一个build目录配置失败直接删目录重来。3.2 编译与产物确认配置成功后编译和安装一步到位cmake --build . --config Release --target install --parallel 8--parallel 8是8线程并行编译机器够好的话能快不少。编译完成后去D:/libssh-0.10.3-install看产物正常情况下有include/ libssh/ libssh.h libssh_version.h sftp.h ... lib/ libssh_static.lib libssh.lib # 有些版本会同时生成一个别名或导入库确认静态库是否生成最简单的方法是看文件大小。libssh_static.lib通常有几百KB甚至更大而动态库对应的导入库才几十KB。用VS自带的dumpbin工具也可以查dumpbin /headers D:/libssh-0.10.3-install/lib/libssh_static.lib输出里如果显示的是静态库特征没有DLL相关的描述信息那就没问题。编译日志建议留一份后面如果链接出问题回头翻日志能确认当时的编译配置到底是什么状态。4. 静态库的链接使用真正容易踩坑的地方编译成功只是第一步把静态库正确链接进工程才是真正检验功课的地方。这个阶段踩坑的人最多因为涉及IDE工程配置和库依赖关系。4.1 使用静态库必须做的三件事在VS2015工程里使用这份静态库有三件事缺一不可。第一件配置头文件路径。在项目属性里把D:/libssh-0.10.3-install/include加到C/C常规附加包含目录。第二件定义LIBSSH_STATIC宏。这是libssh头文件里的一个编译开关。看源码就知道libssh.h里根据LIBSSH_STATIC是否定义来决定LIBSSH_API是空还是__declspec(dllimport)。不定义这个宏头文件会默认把API声明成从dll导入链接时就会报一堆LNK2019。这个宏要在预处理器定义里加LIBSSH_STATIC第三件把依赖库全部加到链接器附加依赖项。这里不能只加libssh_static.lib它依赖的OpenSSL库和Windows系统库也要一并加上。我这边实际可用的最小集合是libssh_static.lib libssl.lib libcrypto.lib crypt32.lib ws2_32.lib advapi32.lib user32.libws2_32.lib是Windows sockets实现SSH通信底层离不开socketcrypt32.lib和advapi32.lib提供证书和加密相关APIuser32.lib在外层链接时偶尔会被用到加上不影响什么。链接顺序上建议libssh和OpenSSL的库放前面系统库放后面可以减少一部分符号解析顺序问题。代码层面和普通用法一样#include libssh/libssh.h #include libssh/sftp.h只要上面的配置都到位编译链接就能过。我在这一步卡过一整个下午最后发现就是漏了LIBSSH_STATIC宏链接器报的一堆unresolved external symbol瞬间全消失。4.2 运行库模式不一致引发的链式报错VS编译时有个运行库设置在工程属性的C/C代码生成里Release默认是/MD也就是动态链接到C运行时库/MT则是把C运行时静态链接进来。这个设置和libssh编译时的运行库模式必须保持一致否则链接阶段会出现经典的LNK2038错误。这个LNK2038报错信息里会明确写RuntimeLibrary mismatch还有_ITERATOR_DEBUG_LEVEL不匹配之类的提示。Debug和Release混用、/MD和/MT混用都会触发。这里的逻辑就是每个库都按自己当时的配置链了对应的C运行时两个库的行李不一致链接器自然不认账。解决方案有两个方向。第一个是把整个工程的运行库设置成和libssh一致如果你没有其他历史包袱CMake默认编出来的libssh静态库在Release下是/MD那你工程Release也保持/MD即可。第二个是如果项目里其他静态库要求/MT那么libssh也要用/MT重新编一份这时CMake配置需要加一个参数cmake .. -DCMAKE_MSVC_RUNTIME_LIBRARYMultiThreaded我个人的习惯是编译第三方库前先想清楚最终要对接什么样的工程配置然后固定下来所有库统一跑同一个运行库模式。最怕的是A库/MD、B库/MT、本项目/MT这种混搭状态下链接错误会变得极其难排查。5. 常见问题与排查技巧实录这节整理我在编译和对接过程中遇到过的实际问题基本都是搜索了很多资料、反复试验才解决的。为了方便查阅我用表格列出来后面再补充一些更具体的排查思路。5.1 编译阶段的典型问题现象可能原因排查与解决CMake报Could NOT find OpenSSLOPENSSL_ROOT_DIR没设置或OpenSSL还没编检查OpenSSL是否已用nmake install_sw安装并显式指定ROOT_DIR和两个LIBRARY路径CMake报Could NOT find PerlPerl没装或不在PATH安装Strawberry Perl并确认perl -v能正常执行CMake报Could NOT find NASM编译OpenSSL时带了汇编优化但没装NASM如果在libssh阶段遇到检查OpenSSL编译时的配置用no-asm可跳过这个依赖编译中报无法打开libcrypto.libOpenSSL库文件不存在或位数与当前工程不匹配确认x64项目对应VC-WIN64Awin32对应VC-WIN32且lib目录下有libcrypto.lib编译报C99语法不支持VS2015对部分C99特性支持不完整升级到VS2015 Update 3当前libssh官方源码一般不会有这个问题这里有一个比较隐蔽的坑是CMake缓存。第一次配置失败后问题修改好了再执行cmake它并不会重新检测所有变量而是基于缓存里已记录的选项继续。我见过很多人在OpenSSL路径写错之后反复改路径参数始终报同一个错最后把build目录整个删掉重新配置就通过了。所以在编译阶段凡是遇到我明明改对了还报错的情况优先怀疑缓存。5.2 链接与运行阶段的问题现象可能原因排查与解决LNK2019 unresolved external symbol ssh_new 等LIBSSH_STATIC宏没定义或libssh_static.lib没加到链接器预处理器定义加LIBSSH_STATIC检查附加依赖项里是否有libssh_static.libLNK2038 RuntimeLibrary mismatch运行库模式不一致/MD和/MT混用统一工程和库的运行库设置必要时用CMAKE_MSVC_RUNTIME_LIBRARY重新编译LNK2019 unresolved ... crypt32/ws2_32缺少Windows系统库在附加依赖项里补上crypt32.lib、ws2_32.lib、advapi32.lib、user32.libLNK2019 unresolved ... EVP_xxx 等OpenSSL符号OpenSSL库没链接或版本不对附加依赖项确认有libssl.lib和libcrypto.lib且路径指向之前编译成功的目录程序运行起来就崩溃和跨模块内存分配释放不一致有关静态库场景下重点是运行库统一同时确认没有混用Debug版库和Release版库链接阶段的错误信息往往很长别被一大串undymbol吓到核心是看第一个报错符号属于谁。比如第一个未解析符号是ssh_new那问题大概率在libssh静态库本身或者LIBSSH_STATIC宏如果第一个符号是EVP_aes_128_cbc那是OpenSSL没链进去比库顺序和依赖问题更常见。前前后后编译过不下三回最大体会就一句话Windows上编译第三方C库最折腾的不是编译本身而是把依赖关系、运行库、位数这些看不见的约束提前想清楚。我到现在还留着当时的CMake配置命令和OpenSSL编译脚本隔了两个月再重编同一套东西翻出来照着跑一遍就能出库。老项目的维护就是这样一次折腾清楚后面全是省心活。本文还有配套的精品资源点击获取 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
