简介面向需要在 Windows 10 与 VS2017 环境下使用 RTMP 推流能力的 C/C 开发者这份资源提供可直接编译的 librtmp.lib 静态库工程省去自行移植与配置依赖的麻烦。压缩包共 238 个文件、约 49.12MB以 163 个头文件为主配合 28 个 dll、8 个 lib 及少量 c 源文件与工程配置涵盖 librtmp 源码、openssl-1.0.1c、zlib-1.2.8 等依赖目录并附带 librtmp.sln 解决方案结构清晰便于按模块查阅。已有 640 人学习下载适合需要快速集成 RTMP 协议栈的中高级开发者参考。读者可直接打开解决方案编译出库文件对照源码理解握手、AMF 编解码与 URL 解析等实现并借助现成依赖配置排查链接错误减少环境搭建与依赖适配的试错成本。1. 在 Win10 上把 librtmp.lib 编出来为什么我劝你先别急着点“生成”Win10 VS2017 编译 librtmp.lib这套组合在流媒体、播放器二次开发、推流模块对接的场景里出现频率极高但真正动手的人十个里有八个会在第一次“生成”时翻车。原因不玄学librtmp 是十多年前的 C 代码自带一套手写 Makefile 和一批老式头文件依赖而 VS2017 默认按现代 MSVC 的严格标准走直接新建一个空项目把源码拖进去大概率收获一屏 LNK2019 和 C4996。更麻烦的是很多人拿到的是“包含引用库和源代码、可直接编译”的压缩包以为双击 sln 就完事结果发现工程配置里的路径全是别人机器上的绝对路径一编译就报找不到 zlib.h。这篇笔记就是按我自己在一台干净 Win10 机器上从零走通的顺序写的先列清环境再讲工程怎么配再讲编译参数怎么取舍最后落到怎么验证这个 .lib 真的能用。适合正在对接 RTMP 推拉流、需要静态库而不是现成 DLL 的开发者也适合被旧工程迁移折腾过一轮、想看清每个配置项到底在干什么的熟手。2. 环境准备VS2017 组件、zlib 依赖和目录结构先摆平2.1 确认 VS2017 装的是哪一档别拿 Community 当万能VS2017 有三个常见版本Community、Professional、Enterprise。编译 librtmp 这种纯 C 静态库Community 完全够用不需要额外授权。真正要盯的是安装时勾选的组件很多人装完发现没有 C 编译器是因为只勾了“.NET 桌面开发”。打开 Visual Studio Installer确认“使用 C 的桌面开发”这一项已勾选右侧摘要里至少要包含MSVC v141 - VS 2017 C x64/x86 生成工具Windows 10 SDK版本 10.0.16299.0 及以上都行我一般用 10.0.17763.0C 通用 Windows 平台工具可选但有些旧工程模板会引用v141 这个工具集编号要记住后面工程属性里“平台工具集”填的就是它。如果你机器上同时装了 VS2015 和 VS2019默认打开 sln 时可能被更高版本接管导致工具集被改成 v142编译出来的 .lib 在只装了 v141 运行库的机器上链接会出问题。常见做法是右键 sln → “重定解决方案目标”手动锁回 v141。# 在 Developer Command Prompt for VS 2017 里确认工具集 cl # 输出应包含: Microsoft (R) C/C Optimizing Compiler Version 19.16.xxxxx for x86cl后面那行版本号 19.16 对应 VS201719.15 是 VS2017 早期版本19.20 就已经是 VS2019 了。版本对不上说明你开的命令行窗口不是 VS2017 的或者 PATH 里混进了别的编译器。2.2 zlib 是硬依赖先把它编成同架构的静态库librtmp 的握手和部分数据处理依赖 zlib压缩包里如果带了 zlib 源码或预编译 lib优先用包内的如果没带就得自己补一个。关键点只有一个架构必须和 librtmp 一致。x86 的 librtmp 去链 x64 的 zlib.lib报错不是“找不到库”而是一堆莫名其妙的 LNK2001 未解析符号很容易被误导到源码问题上。我一般把目录整理成这样避免路径里出现中文和空格D:\build\librtmp\ ├── src\ # 解压出来的 librtmp 源码 ├── zlib\ # zlib 源码或预编译库 │ ├── include\ │ └── lib\ └── output\ # 编译产物放这里zlib 自己编的话用 VS2017 命令行进到 zlib 的 win32 或 contrib\vstudio 目录按架构选 Makefile 或 sln。编完确认zlib.lib和zconf.h、zlib.h都在。这一步别偷懒用网上随便下的 zlib.lib版本和编译选项尤其是 /MD 还是 /MT跟 librtmp 对不上后面链接期会还债。2.3 检查源码里那几个“老古董”头文件librtmp 源码里常见#include sys/time.h、#include unistd.h这类 POSIX 头Windows 下没有。正规的移植版会用#ifdef _WIN32包起来但不同来源的源码包处理程度不一样。打开rtmp.h、rtmp_sys.h、handshake.h扫一眼如果看到裸的sys/time.h没被条件编译包住就得手动补#ifdef _WIN32 #include winsock2.h #include ws2tcpip.h #else #include sys/time.h #include unistd.h #endif另外确认源码里有没有#define _CRT_SECURE_NO_WARNINGS没有的话在工程预处理器里加上否则strcpy、sprintf这类调用会被 C4996 警告刷屏虽然不影响生成但会淹没真正的错误信息。3. 工程配置把“可直接编译”翻译成你自己的路径3.1 新建静态库工程还是直接用包内 sln压缩包说“可直接编译”通常意味着里面有一个 .sln 或 .vcxproj。我的建议是先试着打开包内工程但不要直接信它的配置。打开后第一件事是看“项目属性 → 常规 → 输出目录”和“中间目录”如果里面是C:\Users\某某\Desktop\...这种绝对路径全部改成相对路径$(SolutionDir)output\和$(SolutionDir)obj\。第二件事看“C/C → 附加包含目录”把里面指向别人机器的 zlib 路径删掉换成你自己的D:\build\librtmp\zlib\include。如果包内没有工程文件只有源码那就新建“Windows 桌面 → 静态库”项目把 .c 和 .h 全部添加进去。注意 librtmp 的核心文件是这几个别漏文件作用是否必须rtmp.c协议主逻辑必须handshake.c握手实现必须amf.cAMF 编解码必须hashswf.cSWF 校验哈希推流校验时需要log.c日志输出建议保留parseurl.cURL 解析必须漏掉hashswf.c时编译能过但运行期做某些鉴权推流会直接失败而且报错信息很含糊这是血泪经验。3.2 平台工具集、字符集、运行库三件套怎么定项目属性里这三项必须一次定死后面不再改平台工具集Visual Studio 2017 (v141)字符集使用多字节字符集。librtmp 内部大量char*和sprintf改成 Unicode 会引入一堆转换问题没必要。C/C → 代码生成 → 运行库多线程 (/MT) 或多线程 DLL (/MD)取决于你最终调用方的设置。静态库本身不链接运行库但编译时的 /MT 和 /MD 会影响目标文件里的 CRT 引用方式。我一般跟调用方保持一致独立工具用 /MT跟其他 DLL 混编用 /MD。!-- 在 vcxproj 里对应这几行改完记得保存 -- PropertyGroup Condition$(Configuration)|$(Platform)Release|Win32 PlatformToolsetv141/PlatformToolset CharacterSetMultiByte/CharacterSet RuntimeLibraryMultiThreaded/RuntimeLibrary /PropertyGroupRuntimeLibrary的值MultiThreaded对应 /MTMultiThreadedDLL对应 /MD。改完如果链接方报LNK2038: 检测到“RuntimeLibrary”的不匹配项就是这里和调用方不一致回来对齐即可。3.3 预处理器定义和附加依赖项逐条过“C/C → 预处理器 → 预处理器定义”里加上_CRT_SECURE_NO_WARNINGS _CRT_NONSTDC_NO_DEPRECATE WIN32 _WINDOWS前两个压掉老式 CRT 函数的警告后两个让源码里的 Windows 分支生效。如果源码里有NO_CRYPTO之类的开关按包内说明决定要不要加不加会引入 OpenSSL 依赖那就不是“只编一个 .lib”的事了。“链接器 → 输入 → 附加依赖项”填ws2_32.lib;zlib.lib;。ws2_32 是 Winsocklibrtmp 做网络连接必须zlib.lib 路径在“链接器 → 常规 → 附加库目录”里指向D:\build\librtmp\zlib\lib。顺序上 ws2_32 在前问题不大但 zlib 一定要在否则inflate、deflate系列符号全部未解析。3.4 编译前最后一遍检查清单动手点“生成”之前按这个顺序扫一遍能省掉大半返工解决方案平台选 Win32 还是 x64和你的 zlib 架构一致配置选 ReleaseDebug 版 .lib 带调试信息发布时别混用附加包含目录里没有中文路径、没有别人机器的盘符输出目录存在或者至少父目录存在MSBuild 不会自动建多级目录源码文件编码是 UTF-8 无 BOM 或 GBK混编码会导致中文注释行报 C2001。4. 编译与产物核对.lib 出来了不等于能用4.1 生成命令与常见输出解读在 VS2017 里直接“生成解决方案”即可也可以用命令行复现方便排查# 在 Developer Command Prompt for VS 2017 中进入工程目录 msbuild librtmp.sln /p:ConfigurationRelease /p:PlatformWin32 /v:minimal/p:Configuration和/p:Platform必须和你在 IDE 里选的一致/v:minimal只输出关键信息报错时改成/v:detailed能看到具体是哪个文件哪一行。生成成功后输出目录里应该有librtmp.lib大小通常在几百 KB 量级。如果只有几十 KB多半是只编进去了一两个 .c回去检查“解决方案资源管理器”里文件是否都带上了小箭头表示参与编译。4.2 用 dumpbin 验证符号别等调用方报错才发现.lib 生成后第一件事不是拿去用而是查符号表dumpbin /symbols output\librtmp.lib | findstr RTMP_Init RTMP_Connect RTMP_SendPacket正常应该能看到这几个符号的External记录。如果RTMP_Init找不到说明 rtmp.c 没参与编译如果符号前面带__imp_前缀说明某个环节把它当成了导入库检查是不是误把 DLL 的 .lib 混进来了。这一步是黑匣子能提前把“库是空的”和“库是 DLL 导入库”两种情况区分开。4.3 写一个最小调用程序做链接验证光有符号还不够真正能链上才算数。新建一个控制台空项目引用这个 .lib写十行代码#include stdio.h #include rtmp.h int main(void) { RTMP *r RTMP_Alloc(); /* 分配 RTMP 上下文 */ if (r NULL) { printf(alloc failed\n); return 1; } RTMP_Init(r); /* 初始化默认参数 */ printf(librtmp linked ok\n); RTMP_Free(r); /* 释放避免泄漏 */ return 0; }链接器附加依赖项填librtmp.lib;ws2_32.lib;zlib.lib;包含目录指向 librtmp 源码目录和 zlib 的 include。能编过并打印出librtmp linked ok说明静态库的符号、CRT 设置、依赖库三者都对上了。这一步跑不通别急着写业务代码先回来对运行库和架构。5. 避坑排查五条我真实踩过的记录5.1 现象LNK2019 未解析的外部符号__imp__WSAStartup原因只链了 ws2_32.lib 的导入库形式或者工程里误加了#pragma comment(lib, ws2_32.lib)但平台选错。更隐蔽的一种是源码里 Winsock 头包含顺序不对winsock2.h在windows.h之后被包含导致宏定义冲突。解决确保“附加依赖项”里是ws2_32.lib且源码里#include winsock2.h放在#include windows.h之前。如果还不行用dumpbin /symbols查 ws2_32.lib 里到底有没有这个符号确认你链的是系统库而不是某个同名野库。5.2 现象编译通过运行时报“无法定位程序输入点 inflateEnd”原因zlib 用的是 DLL 版导入库但运行目录里没有 zlib1.dll或者静态库编译时 /MD调用方 /MTCRT 堆不一致导致 zlib 内部状态错乱。解决统一用 zlib 静态库zlibstatic.lib 或自己编的 zlib.lib并在调用方工程里同样设置 /MT 或 /MD。如果必须用 DLL 版把 zlib1.dll 放到 exe 同目录别指望系统路径。5.3 现象C4996 警告几百条真正的错误被淹没原因没定义_CRT_SECURE_NO_WARNINGSMSVC 对strcpy、sprintf、fopen全部告警。解决预处理器定义里加上_CRT_SECURE_NO_WARNINGS和_CRT_NONSTDC_NO_DEPRECATE。不建议用#pragma warning(disable:4996)全局压那样连别的文件的真实告警也一起吞了排查时更痛苦。5.4 现象x64 工程链接 x86 的 zlib报一堆 LNK2001原因架构不匹配时链接器不会直接说“架构不对”而是找不到符号因为 x86 的 .lib 里符号修饰方式和 x64 不同。解决用dumpbin /headers zlib.lib | findstr machine看架构x86 显示14C machine (x86)x64 显示8664 machine (x64)。两边必须一致不一致就重编 zlib。5.5 现象包内 sln 打开后提示“项目不可用”或工具集自动跳到 v142原因sln 里记录的 VS 版本高于本机或者本机装了更高版本 VS 并设置了默认打开方式。解决右键 sln → “重定解决方案目标”选 v141如果项目直接不可用用文本编辑器打开 .vcxproj把PlatformToolset改成v141把WindowsTargetPlatformVersion改成你本机实际安装的 SDK 版本号再重新打开。6. 装完怎么验证三层验证法从符号到实际握手6.1 第一层符号层验证前面 dumpbin 查符号是最快的一层但只证明“符号在”。我一般会把关键符号列成一个清单逐条 grepdumpbin /symbols output\librtmp.lib symbols.txt findstr /C:RTMP_Alloc /C:RTMP_Init /C:RTMP_Connect /C:RTMP_SendPacket /C:RTMP_Free symbols.txt五条全中说明核心 API 都编进去了。少任何一条回去看对应 .c 文件是否在工程里。这一层花不了一分钟但能挡掉后面 80% 的“库是残的”问题。6.2 第二层链接层验证用 4.3 那个最小程序分别用 Debug 和 Release、Win32 和 x64 各链一遍。四种组合里至少 Release 你的目标架构要过。链接时把“链接器 → 常规 → 显示进度”打开能看到它实际找了哪些库、从哪个路径找的路径不对一眼就能看出来。如果出现LNK4098: 默认库“MSVCRT”与其他库的使用冲突就是运行库设置不一致回 3.2 对齐。6.3 第三层运行层验证真正跑一次 RTMP 连接才算数。找一个可用的 RTMP 服务地址本地自建或测试环境写个最小连接程序#include rtmp.h int main(void) { RTMP *r RTMP_Alloc(); RTMP_Init(r); if (!RTMP_SetupURL(r, (char *)rtmp://127.0.0.1:1935/live/test)) { printf(setup url failed\n); return 1; } RTMP_EnableWrite(r); /* 推流模式拉流则去掉这行 */ if (!RTMP_Connect(r, NULL)) { printf(connect failed, code%d\n, RTMP_GetLastError(r)); return 1; } printf(rtmp connected\n); RTMP_Close(r); RTMP_Free(r); return 0; }RTMP_GetLastError能给出具体错误码连不上时先看这个再抓包看握手包有没有发出去。能打印rtmp connected这个 .lib 才算真正可用。我习惯把这三层验证写成一个批处理每次重新编库都跑一遍从那以后再也没有出现过“库编出来了、业务一调就崩”的情况。希望帮到你。本文还有配套的精品资源点击获取
简介面向需要在 Windows 10 与 VS2017 环境下使用 RTMP 推流能力的 C/C 开发者这份资源提供可直接编译的 librtmp.lib 静态库工程省去自行移植与配置依赖的麻烦。压缩包共 238 个文件、约 49.12MB以 163 个头文件为主配合 28 个 dll、8 个 lib 及少量 c 源文件与工程配置涵盖 librtmp 源码、openssl-1.0.1c、zlib-1.2.8 等依赖目录并附带 librtmp.sln 解决方案结构清晰便于按模块查阅。已有 640 人学习下载适合需要快速集成 RTMP 协议栈的中高级开发者参考。读者可直接打开解决方案编译出库文件对照源码理解握手、AMF 编解码与 URL 解析等实现并借助现成依赖配置排查链接错误减少环境搭建与依赖适配的试错成本。1. 在 Win10 上把 librtmp.lib 编出来为什么我劝你先别急着点“生成”Win10 VS2017 编译 librtmp.lib这套组合在流媒体、播放器二次开发、推流模块对接的场景里出现频率极高但真正动手的人十个里有八个会在第一次“生成”时翻车。原因不玄学librtmp 是十多年前的 C 代码自带一套手写 Makefile 和一批老式头文件依赖而 VS2017 默认按现代 MSVC 的严格标准走直接新建一个空项目把源码拖进去大概率收获一屏 LNK2019 和 C4996。更麻烦的是很多人拿到的是“包含引用库和源代码、可直接编译”的压缩包以为双击 sln 就完事结果发现工程配置里的路径全是别人机器上的绝对路径一编译就报找不到 zlib.h。这篇笔记就是按我自己在一台干净 Win10 机器上从零走通的顺序写的先列清环境再讲工程怎么配再讲编译参数怎么取舍最后落到怎么验证这个 .lib 真的能用。适合正在对接 RTMP 推拉流、需要静态库而不是现成 DLL 的开发者也适合被旧工程迁移折腾过一轮、想看清每个配置项到底在干什么的熟手。2. 环境准备VS2017 组件、zlib 依赖和目录结构先摆平2.1 确认 VS2017 装的是哪一档别拿 Community 当万能VS2017 有三个常见版本Community、Professional、Enterprise。编译 librtmp 这种纯 C 静态库Community 完全够用不需要额外授权。真正要盯的是安装时勾选的组件很多人装完发现没有 C 编译器是因为只勾了“.NET 桌面开发”。打开 Visual Studio Installer确认“使用 C 的桌面开发”这一项已勾选右侧摘要里至少要包含MSVC v141 - VS 2017 C x64/x86 生成工具Windows 10 SDK版本 10.0.16299.0 及以上都行我一般用 10.0.17763.0C 通用 Windows 平台工具可选但有些旧工程模板会引用v141 这个工具集编号要记住后面工程属性里“平台工具集”填的就是它。如果你机器上同时装了 VS2015 和 VS2019默认打开 sln 时可能被更高版本接管导致工具集被改成 v142编译出来的 .lib 在只装了 v141 运行库的机器上链接会出问题。常见做法是右键 sln → “重定解决方案目标”手动锁回 v141。# 在 Developer Command Prompt for VS 2017 里确认工具集 cl # 输出应包含: Microsoft (R) C/C Optimizing Compiler Version 19.16.xxxxx for x86cl后面那行版本号 19.16 对应 VS201719.15 是 VS2017 早期版本19.20 就已经是 VS2019 了。版本对不上说明你开的命令行窗口不是 VS2017 的或者 PATH 里混进了别的编译器。2.2 zlib 是硬依赖先把它编成同架构的静态库librtmp 的握手和部分数据处理依赖 zlib压缩包里如果带了 zlib 源码或预编译 lib优先用包内的如果没带就得自己补一个。关键点只有一个架构必须和 librtmp 一致。x86 的 librtmp 去链 x64 的 zlib.lib报错不是“找不到库”而是一堆莫名其妙的 LNK2001 未解析符号很容易被误导到源码问题上。我一般把目录整理成这样避免路径里出现中文和空格D:\build\librtmp\ ├── src\ # 解压出来的 librtmp 源码 ├── zlib\ # zlib 源码或预编译库 │ ├── include\ │ └── lib\ └── output\ # 编译产物放这里zlib 自己编的话用 VS2017 命令行进到 zlib 的 win32 或 contrib\vstudio 目录按架构选 Makefile 或 sln。编完确认zlib.lib和zconf.h、zlib.h都在。这一步别偷懒用网上随便下的 zlib.lib版本和编译选项尤其是 /MD 还是 /MT跟 librtmp 对不上后面链接期会还债。2.3 检查源码里那几个“老古董”头文件librtmp 源码里常见#include sys/time.h、#include unistd.h这类 POSIX 头Windows 下没有。正规的移植版会用#ifdef _WIN32包起来但不同来源的源码包处理程度不一样。打开rtmp.h、rtmp_sys.h、handshake.h扫一眼如果看到裸的sys/time.h没被条件编译包住就得手动补#ifdef _WIN32 #include winsock2.h #include ws2tcpip.h #else #include sys/time.h #include unistd.h #endif另外确认源码里有没有#define _CRT_SECURE_NO_WARNINGS没有的话在工程预处理器里加上否则strcpy、sprintf这类调用会被 C4996 警告刷屏虽然不影响生成但会淹没真正的错误信息。3. 工程配置把“可直接编译”翻译成你自己的路径3.1 新建静态库工程还是直接用包内 sln压缩包说“可直接编译”通常意味着里面有一个 .sln 或 .vcxproj。我的建议是先试着打开包内工程但不要直接信它的配置。打开后第一件事是看“项目属性 → 常规 → 输出目录”和“中间目录”如果里面是C:\Users\某某\Desktop\...这种绝对路径全部改成相对路径$(SolutionDir)output\和$(SolutionDir)obj\。第二件事看“C/C → 附加包含目录”把里面指向别人机器的 zlib 路径删掉换成你自己的D:\build\librtmp\zlib\include。如果包内没有工程文件只有源码那就新建“Windows 桌面 → 静态库”项目把 .c 和 .h 全部添加进去。注意 librtmp 的核心文件是这几个别漏文件作用是否必须rtmp.c协议主逻辑必须handshake.c握手实现必须amf.cAMF 编解码必须hashswf.cSWF 校验哈希推流校验时需要log.c日志输出建议保留parseurl.cURL 解析必须漏掉hashswf.c时编译能过但运行期做某些鉴权推流会直接失败而且报错信息很含糊这是血泪经验。3.2 平台工具集、字符集、运行库三件套怎么定项目属性里这三项必须一次定死后面不再改平台工具集Visual Studio 2017 (v141)字符集使用多字节字符集。librtmp 内部大量char*和sprintf改成 Unicode 会引入一堆转换问题没必要。C/C → 代码生成 → 运行库多线程 (/MT) 或多线程 DLL (/MD)取决于你最终调用方的设置。静态库本身不链接运行库但编译时的 /MT 和 /MD 会影响目标文件里的 CRT 引用方式。我一般跟调用方保持一致独立工具用 /MT跟其他 DLL 混编用 /MD。!-- 在 vcxproj 里对应这几行改完记得保存 -- PropertyGroup Condition$(Configuration)|$(Platform)Release|Win32 PlatformToolsetv141/PlatformToolset CharacterSetMultiByte/CharacterSet RuntimeLibraryMultiThreaded/RuntimeLibrary /PropertyGroupRuntimeLibrary的值MultiThreaded对应 /MTMultiThreadedDLL对应 /MD。改完如果链接方报LNK2038: 检测到“RuntimeLibrary”的不匹配项就是这里和调用方不一致回来对齐即可。3.3 预处理器定义和附加依赖项逐条过“C/C → 预处理器 → 预处理器定义”里加上_CRT_SECURE_NO_WARNINGS _CRT_NONSTDC_NO_DEPRECATE WIN32 _WINDOWS前两个压掉老式 CRT 函数的警告后两个让源码里的 Windows 分支生效。如果源码里有NO_CRYPTO之类的开关按包内说明决定要不要加不加会引入 OpenSSL 依赖那就不是“只编一个 .lib”的事了。“链接器 → 输入 → 附加依赖项”填ws2_32.lib;zlib.lib;。ws2_32 是 Winsocklibrtmp 做网络连接必须zlib.lib 路径在“链接器 → 常规 → 附加库目录”里指向D:\build\librtmp\zlib\lib。顺序上 ws2_32 在前问题不大但 zlib 一定要在否则inflate、deflate系列符号全部未解析。3.4 编译前最后一遍检查清单动手点“生成”之前按这个顺序扫一遍能省掉大半返工解决方案平台选 Win32 还是 x64和你的 zlib 架构一致配置选 ReleaseDebug 版 .lib 带调试信息发布时别混用附加包含目录里没有中文路径、没有别人机器的盘符输出目录存在或者至少父目录存在MSBuild 不会自动建多级目录源码文件编码是 UTF-8 无 BOM 或 GBK混编码会导致中文注释行报 C2001。4. 编译与产物核对.lib 出来了不等于能用4.1 生成命令与常见输出解读在 VS2017 里直接“生成解决方案”即可也可以用命令行复现方便排查# 在 Developer Command Prompt for VS 2017 中进入工程目录 msbuild librtmp.sln /p:ConfigurationRelease /p:PlatformWin32 /v:minimal/p:Configuration和/p:Platform必须和你在 IDE 里选的一致/v:minimal只输出关键信息报错时改成/v:detailed能看到具体是哪个文件哪一行。生成成功后输出目录里应该有librtmp.lib大小通常在几百 KB 量级。如果只有几十 KB多半是只编进去了一两个 .c回去检查“解决方案资源管理器”里文件是否都带上了小箭头表示参与编译。4.2 用 dumpbin 验证符号别等调用方报错才发现.lib 生成后第一件事不是拿去用而是查符号表dumpbin /symbols output\librtmp.lib | findstr RTMP_Init RTMP_Connect RTMP_SendPacket正常应该能看到这几个符号的External记录。如果RTMP_Init找不到说明 rtmp.c 没参与编译如果符号前面带__imp_前缀说明某个环节把它当成了导入库检查是不是误把 DLL 的 .lib 混进来了。这一步是黑匣子能提前把“库是空的”和“库是 DLL 导入库”两种情况区分开。4.3 写一个最小调用程序做链接验证光有符号还不够真正能链上才算数。新建一个控制台空项目引用这个 .lib写十行代码#include stdio.h #include rtmp.h int main(void) { RTMP *r RTMP_Alloc(); /* 分配 RTMP 上下文 */ if (r NULL) { printf(alloc failed\n); return 1; } RTMP_Init(r); /* 初始化默认参数 */ printf(librtmp linked ok\n); RTMP_Free(r); /* 释放避免泄漏 */ return 0; }链接器附加依赖项填librtmp.lib;ws2_32.lib;zlib.lib;包含目录指向 librtmp 源码目录和 zlib 的 include。能编过并打印出librtmp linked ok说明静态库的符号、CRT 设置、依赖库三者都对上了。这一步跑不通别急着写业务代码先回来对运行库和架构。5. 避坑排查五条我真实踩过的记录5.1 现象LNK2019 未解析的外部符号__imp__WSAStartup原因只链了 ws2_32.lib 的导入库形式或者工程里误加了#pragma comment(lib, ws2_32.lib)但平台选错。更隐蔽的一种是源码里 Winsock 头包含顺序不对winsock2.h在windows.h之后被包含导致宏定义冲突。解决确保“附加依赖项”里是ws2_32.lib且源码里#include winsock2.h放在#include windows.h之前。如果还不行用dumpbin /symbols查 ws2_32.lib 里到底有没有这个符号确认你链的是系统库而不是某个同名野库。5.2 现象编译通过运行时报“无法定位程序输入点 inflateEnd”原因zlib 用的是 DLL 版导入库但运行目录里没有 zlib1.dll或者静态库编译时 /MD调用方 /MTCRT 堆不一致导致 zlib 内部状态错乱。解决统一用 zlib 静态库zlibstatic.lib 或自己编的 zlib.lib并在调用方工程里同样设置 /MT 或 /MD。如果必须用 DLL 版把 zlib1.dll 放到 exe 同目录别指望系统路径。5.3 现象C4996 警告几百条真正的错误被淹没原因没定义_CRT_SECURE_NO_WARNINGSMSVC 对strcpy、sprintf、fopen全部告警。解决预处理器定义里加上_CRT_SECURE_NO_WARNINGS和_CRT_NONSTDC_NO_DEPRECATE。不建议用#pragma warning(disable:4996)全局压那样连别的文件的真实告警也一起吞了排查时更痛苦。5.4 现象x64 工程链接 x86 的 zlib报一堆 LNK2001原因架构不匹配时链接器不会直接说“架构不对”而是找不到符号因为 x86 的 .lib 里符号修饰方式和 x64 不同。解决用dumpbin /headers zlib.lib | findstr machine看架构x86 显示14C machine (x86)x64 显示8664 machine (x64)。两边必须一致不一致就重编 zlib。5.5 现象包内 sln 打开后提示“项目不可用”或工具集自动跳到 v142原因sln 里记录的 VS 版本高于本机或者本机装了更高版本 VS 并设置了默认打开方式。解决右键 sln → “重定解决方案目标”选 v141如果项目直接不可用用文本编辑器打开 .vcxproj把PlatformToolset改成v141把WindowsTargetPlatformVersion改成你本机实际安装的 SDK 版本号再重新打开。6. 装完怎么验证三层验证法从符号到实际握手6.1 第一层符号层验证前面 dumpbin 查符号是最快的一层但只证明“符号在”。我一般会把关键符号列成一个清单逐条 grepdumpbin /symbols output\librtmp.lib symbols.txt findstr /C:RTMP_Alloc /C:RTMP_Init /C:RTMP_Connect /C:RTMP_SendPacket /C:RTMP_Free symbols.txt五条全中说明核心 API 都编进去了。少任何一条回去看对应 .c 文件是否在工程里。这一层花不了一分钟但能挡掉后面 80% 的“库是残的”问题。6.2 第二层链接层验证用 4.3 那个最小程序分别用 Debug 和 Release、Win32 和 x64 各链一遍。四种组合里至少 Release 你的目标架构要过。链接时把“链接器 → 常规 → 显示进度”打开能看到它实际找了哪些库、从哪个路径找的路径不对一眼就能看出来。如果出现LNK4098: 默认库“MSVCRT”与其他库的使用冲突就是运行库设置不一致回 3.2 对齐。6.3 第三层运行层验证真正跑一次 RTMP 连接才算数。找一个可用的 RTMP 服务地址本地自建或测试环境写个最小连接程序#include rtmp.h int main(void) { RTMP *r RTMP_Alloc(); RTMP_Init(r); if (!RTMP_SetupURL(r, (char *)rtmp://127.0.0.1:1935/live/test)) { printf(setup url failed\n); return 1; } RTMP_EnableWrite(r); /* 推流模式拉流则去掉这行 */ if (!RTMP_Connect(r, NULL)) { printf(connect failed, code%d\n, RTMP_GetLastError(r)); return 1; } printf(rtmp connected\n); RTMP_Close(r); RTMP_Free(r); return 0; }RTMP_GetLastError能给出具体错误码连不上时先看这个再抓包看握手包有没有发出去。能打印rtmp connected这个 .lib 才算真正可用。我习惯把这三层验证写成一个批处理每次重新编库都跑一遍从那以后再也没有出现过“库编出来了、业务一调就崩”的情况。希望帮到你。本文还有配套的精品资源点击获取
