DLL 编译好了发给对方对方右键属性一看“详细信息”那一栏干干净净——产品名称空白、文件版本空白、版权空白甚至“文件说明”都是空的。有些系统在加载时会把这些字段当成可信度参考空白信息会让对方的第一反应变成“这东西来路不明”。更尴尬的是明明代码里写了个版本号字符串属性面板却始终显示 0.0.0.0因为那玩意儿是运行时接口跟资源里的版本信息根本是两套东西。这篇内容聊的就是这件事在 Linux 环境下用 MinGW-w64 交叉编译出 Windows DLL同时把版本信息VS_VERSION_INFO和版权声明一起写进 PE 文件的资源节。它解决的是“构建产物信息完整度”的问题适合已经在做跨平台构建、手上有 Makefile 或 CMake 工程、但发出去的二进制总被质疑“不专业”的同学。整套流程不依赖任何 Windows 机器纯 Linux 命令行就能闭环编译、塞资源、验证一条龙。1. 版本信息不在代码里而在 PE 的 .rsrc 节1.1 一个常见的认知错位很多人第一次处理这件事会本能地在 C 代码里写一个GetVersion()函数导出然后觉得“版本信息有了”。但 Windows 资源管理器属性面板读的根本不是你的导出函数它读的是 PE 文件里的资源目录Resource Directory具体落在.rsrc节。这个节里可以放图标、字符串表、对话框模板、清单文件以及本篇的主角版本信息资源。这个信息有两个显著特点。第一它是静态数据编译完就固化了运行时不用执行任何代码就能被系统读取。第二它有自己的版本号表示法是四个 16 位整数0 到 65535不是随便一个字符串。你在代码里#define VERSION 1.4.2对资源没有任何影响资源里的FILEVERSION 1,4,2,0是独立维护的。这就是为什么很多项目代码里版本号写着 1.4.2属性面板里却是 0.0.0.0——压根没人往资源里写过东西。所以正确的理解是给 DLL 加版本信息本质上是往 PE 里塞一段结构化元数据它跟你的 C 源码、跟你导出的函数、跟你的main函数都无关。它由资源脚本定义由资源编译器编译由链接器合并进最终产物。三个环节缺一不可。1.2 交叉编译链里谁负责写资源在 Windows 上用 Visual Studio 的同学对这件事没什么感觉因为.rc文件天然被工程系统接管了你只要在资源视图里点几下、填几个框构建时自动就编进去了。转到 Linux 交叉编译这条链路需要自己手动串起来。MinGW-w64 提供的工具链里负责资源这一步的可执行文件叫windres。它不是编译器也不是链接器而是一个资源编译器吃.rc文本脚本吐出一个 COFF 格式的目标文件.o这个.o里面只有资源节没有代码。后面的gcc或ld把这个.o和其他.o一起链接资源节就被并进最终 DLL 的.rsrc里。理解这个分工能省掉很多困惑。比如有人问“为什么我在.rc里写的字符串在strings mylib.dll里搜不到”因为strings默认只扫可打印的连续字节而资源里的字符串是 UTF-16LE 存储的中间夹着\0扫不出来很正常。再比如有人问“为什么我改了.rc但 DLL 属性没变”大概率是改了脚本但没重新跑windres或者windres的输出没参与链接。这条链路是显式的每一步都要自己盯着。2. 备齐三件套编译器、资源编译器、链接器2.1 装完之后先确认工具名主流发行版的软件源里都能找到 MinGW-w64 的交叉工具链包名通常带目标三元组前缀。64 位目标一般是x86_64-w64-mingw32-开头32 位目标则是i686-w64-mingw32-。装完之后/usr/bin下会多出一批可执行文件其中最常用的三个是工具作用典型调用x86_64-w64-mingw32-gcc编译 C 源码、驱动链接生成.o和最终.dllx86_64-w64-mingw32-windres编译.rc资源脚本生成只含资源的.ox86_64-w64-mingw32-objdump反查 PE 结构检查.rsrc节是否存在这三个缺一不可。有些精简安装只给了gcc没给windres症状是跑到资源那一步报 command not found。装包时如果拿不准直接搜带mingw的包一次性装全比事后逐个补省事。注意如果你的机器上同时存在 32 位和 64 位两套工具链务必全程用同一套。混用最典型的后果是windres编出来的资源.o是 32 位机器码格式链接 64 位 DLL 时报file format not recognized或者更隐蔽的relocation truncated。2.2 一条命令验证工具链完整性装完别急着写代码先跑个冒烟测试。最省事的办法是让gcc打印版本再让windres打印帮助两者都能正常输出说明路径没问题x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-windres --versionwindres的输出里会带上它所依赖的 binutils 版本。这一步还有一个隐藏作用确认windres用的是哪一个 binutils。某些系统上windres和objdump来自不同版本处理某些资源语法时会表现不一致。实测下来同一发行版源里装的包通常是一致的但如果你手动拼过工具链就得留意。顺带提一句windres支持--help列出一大堆参数但真正日常用得上的就那么几个-i指定输入-o指定输出-O coff指定输出格式-I加头文件搜索路径-c指定输入代码页。参数少意味着好记但也意味着遇到问题时能调的空间有限——后面讲编码那节会碰到。3. 先把 DLL 编出来导出符号的两种写法3.1__declspec(dllexport)与.def文件怎么选资源是给已有产物“贴标签”前提是产物本身能编出来。MinGW 下导出函数有两条路理解它们的差异对后面链接资源有直接影响。第一条路是在源码里标注。Windows 平台的头文件习惯用宏切换导入导出#ifdef MYLIB_EXPORTS #define MYLIB_API __declspec(dllexport) #else #define MYLIB_API __declspec(dllimport) #endif MYLIB_API int mylib_add(int a, int b);编译 DLL 时定义MYLIB_EXPORTS导出表里就会出现mylib_add。这条路的好处是声明和定义在一个文件里改动方便。坏处是每个导出函数都得贴上宏漏一个就少一个导出而且导出名受调用约定影响会被修饰。第二条路是用.def文件集中声明LIBRARY mylib EXPORTS mylib_add 1 mylib_sub 2.def的好处是导出表一目了然能精确控制序号1、2也能用PRIVATE、DATA等修饰符处理特殊情况。缺点是多维护一个文件函数增删容易忘同步。我自己的习惯是导出的函数数量少于十个、且不涉及复杂调用约定时直接在源码里标__declspec(dllexport)数量多、需要稳定序号、或者要给第三方做 ABI 兼容时用.def。两种方式可以混用但没必要混用反而容易出现“导出了但名字不对”的排查成本。3.2 32 位 stdcall 的名字修饰要先想清楚如果目标平台是 32 位且导出函数用了__stdcall调用约定导出名会变成_mylib_add8这种带后缀的形式。这个修饰规则在.def里写mylib_add时会导致链接器找不到符号因为你声明的名字和实际符号名对不上。解决办法有两个。一是在.def里写完整的修饰名二是给链接器加--kill-atx86_64-w64-mingw32-gcc -shared -o mylib.dll mylib.o \ -Wl,--kill-at \ -Wl,--out-implib,libmylib.dll.a--kill-at的作用是在生成导出表时把N后缀削掉让 DLL 对外暴露的名字是干净的mylib_add。注意这个选项只影响 32 位64 位下 stdcall 和 cdecl 在调用约定上已经统一不存在名字修饰差异加了也无害但没必要。顺带说一句导入库。-Wl,--out-implib,libmylib.dll.a会同时生成一个.dll.a文件这是给 MinGW 程序链接用的导入库。如果你只发 DLL 不发这个导入库别人用 MinGW 链接时会报 undefined reference。用 MSVC 的人则靠 DLL 本身或者.lib导入库MinGW 下可以用--out-implib生成.a再借助dlltool转.lib但这是另一条线本篇不展开。3.3 把编译链接命令拆开看一条命令也能编出 DLL但拆开更利于排查也更容易在 Makefile 里组织# 1. 编译源码为目标文件 x86_64-w64-mingw32-gcc -c -O2 -DMYLIB_EXPORTS \ -o mylib.o mylib.c # 2. 编译资源脚本为资源目标文件 x86_64-w64-mingw32-windres -i version.rc -O coff \ -o version.o # 3. 链接成 DLL x86_64-w64-mingw32-gcc -shared \ -o mylib.dll mylib.o version.o \ -Wl,--out-implib,libmylib.dll.a第三步里资源.o和普通.o地位完全相同都是链接输入。这就是整个流程最关键的一点资源不是特殊的东西它就是目标文件里的一个节。理解这一点后面所有关于“为什么资源丢了”“为什么链接报重复定义”的问题都能自己想明白。-O2和-DMYLIB_EXPORTS这些属于常规选项不必多说。倒是-shared值得强调一下它告诉链接器生成动态库而不是可执行文件会连带上-e _DllMainCRTStartup之类的东西最终产物才会带有DLL标志位。少了它编出来的会是.exe虽然改个后缀也能当 DLL 加载但属性面板里的文件类型显示会很难看。4. 版本资源脚本逐字段把它写透4.1 骨架结构与必须写对的固定字段.rc文件里版本信息的标准写法是一个VS_VERSION_INFO块语法上属于资源定义不是 C 代码但支持#include和#define因为windres会先跑一遍预处理器。最简完整骨架如下#include winver.h VS_VERSION_INFO VERSIONINFO FILEVERSION 1,4,2,0 PRODUCTVERSION 1,4,2,0 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x2L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 040904b0 BEGIN VALUE CompanyName, Example Studio\0 VALUE FileDescription, Example math helper DLL\0 VALUE FileVersion, 1.4.2.0\0 VALUE InternalName, mylib\0 VALUE LegalCopyright, Copyright (C) 2024 Example Studio\0 VALUE OriginalFilename, mylib.dll\0 VALUE ProductName, Example Lib\0 VALUE ProductVersion, 1.4.2.0\0 END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x409, 1200 END END固定字段里几个容易写错的地方FILEFLAGSMASK一般写0x3fL表示关注低 6 位的标志。FILEFLAGS写0x0L表示正式版如果写0x1L表示调试版属性面板上会显示“调试”。这个细节常被忽略但发版时如果误标成调试版别人看属性会觉得你发的是内部构建。FILEOS写0x40004L对应VOS_NT_WINDOWS32。这个值不要瞎填填错不会导致加载失败但部分安装包校验工具会读它做平台匹配。FILETYPE是重点DLL 必须是0x2LVFT_DLL。写0x1L是应用程序属性面板里“文件类型”那一栏会显示成“应用程序”虽然不影响运行但很掉价。FILESUBTYPE对 DLL 一般写0x0L未知如果写错了会显示成驱动之类的分类。FILEVERSION和PRODUCTVERSION各由四个 0 到 65535 的整数组成中间用逗号分隔不能有空格以外的其他分隔符也不能超过范围。我第一次写的时候用了点分形式1.4.2.0windres直接报语法错误因为这个位置要的是整数列表。4.2 字符串块版权和产品名放哪里字符串块就是属性面板“详细信息”里那一列一列的内容。字段名是固定的几个键大小写敏感写了系统才会认键名属性面板对应项建议值CompanyName公司组织或作者名FileDescription文件说明一句话描述 DLL 用途FileVersion文件版本与FILEVERSION对应InternalName内部名称不带扩展名的模块名LegalCopyright版权完整的版权声明OriginalFilename原始文件名带.dll后缀ProductName产品名称产品线名称ProductVersion产品版本与PRODUCTVERSION对应LegalTrademarks商标选填Comments备注选填适合放构建信息每个VALUE的第二个参数是字符串必须以\0结尾。这是资源里的硬性要求字符串在资源节里是连续存储的靠\0定界。漏了这个结尾属性面板上可能显示正常但某些解析工具会把下一条字符串一起读进来串成一长串乱码。我见过一个案例InternalName少了\0结果在某个工具里显示成mylibmylib.dll因为把下一条OriginalFilename的前面几个字符也吞了。另外注意每个VALUE行的逗号、引号、分号都是语法的一部分缺一个就报错。windres的错误信息通常指向行号但有时会指到下一行因为它是在解析到下一个 token 才发现上一行没闭合。4.3 版本号的两套表示必须同步这是实践中出错最多的地方。FILEVERSION 1,4,2,0是机器读的整型VALUE FileVersion, 1.4.2.0\0是人读的字符串它们是两套独立的数据系统不会帮你同步。如果你只改了一个属性面板上“文件版本”那一栏读整型转成的点分形式和“产品版本”那一栏读字符串就会不一致。所以工程上要么用脚本生成.rc要么在两个地方都引用同一个宏。后者更简单#define VER_MAJOR 1 #define VER_MINOR 4 #define VER_PATCH 2 #define VER_BUILD 0 #define VER_STR 1.4.2.0 VS_VERSION_INFO VERSIONINFO FILEVERSION VER_MAJOR,VER_MINOR,VER_PATCH,VER_BUILD PRODUCTVERSION VER_MAJOR,VER_MINOR,VER_PATCH,VER_BUILD ... VALUE FileVersion, VER_STR \0windres走预处理器#define能正常展开。这样构建系统只需要在一个地方改版本号-DVER_MAJOR1之类的编译选项也能覆盖非常适合 CI 里根据 git tag 自动注入版本。还有一个细节字符串形式的版本号建议固定写四段。有些项目喜欢写1.4.2属性面板上也能显示但某些安装包比对工具做版本比较时会按四段解析少一段可能被判成非法或者补零规则不一致。统一写四段最稳。4.4 本地化块多语言共存怎么写BLOCK 040904b0这一串不是随便编的。前四位0409是语言 ID美式英语后四位04b0是代码页1200 的十六进制即 Unicode。两者拼起来构成一个“语言-代码页”组合标识。VarFileInfo里的Translation值要和它对应0x409, 1200。如果只做中英双语可以并列写两个BLOCKBLOCK StringFileInfo BEGIN BLOCK 040904b0 BEGIN VALUE CompanyName, Example Studio\0 VALUE LegalCopyright, Copyright (C) 2024 Example Studio\0 END BLOCK 080404b0 BEGIN VALUE CompanyName, 示例工作室\0 VALUE LegalCopyright, 版权所有 (C) 2024 示例工作室\0 END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x409, 1200, 0x804, 1200 END0804是简体中文的语言 ID04b0还是 Unicode 代码页。Translation那行可以并列多组用逗号隔开。但这里有个非常现实的问题中文写进去之后windres处理编码时经常翻车属性面板上显示一堆问号或者乱码。这就是下一节要专门处理的事。5. 编码这道坎绕不开但要踩得明白5.1 问题根源windres 需要知道你的文件是什么编码.rc文件在磁盘上是一堆字节windres必须知道这些字节按什么编码解释才能正确转成资源节里的 UTF-16。它有一个-c或--codepage参数专门指定输入文件的代码页。不给的话它会用系统区域设置推导而 Linux 环境的 locale 和 Windows 完全不同推导结果经常是错的。症状很典型英文全对中文变成问号或者方块或者干脆编译时报某行有非法字符。这时候先别怀疑语法八成是编码没对上。处理办法有两条主流路线各有适用场景。第一条是把.rc存成 UTF-8不带 BOM然后显式告诉windres输入是 65001x86_64-w64-mingw32-windres -i version.rc -O coff \ -c 65001 -o version.o65001就是 UTF-8 的代码页号。这条路线的好处是文件本身通用Git 里存着不别扭编辑器里看着也正常。坏处是对windres版本有要求比较老的版本对 65001 支持不完整可能在展开宏或者处理字符串拼接时出偏差。第二条是把.rc存成 GBK代码页 936然后用-c 936x86_64-w64-mingw32-windres -i version.rc -O coff \ -c 936 -o version.o这条路线兼容性更好因为 936 是中文 Windows 的默认代码页windres处理得最成熟。代价是文件在 Linux 侧的编辑器里默认可能显示乱码需要手动切编码Git diff 里也是一堆不可读字节代码评审体验差。我自己的选择是 UTF-8 加-c 65001并且把这个参数固化进 Makefile所有人跑构建都不用操心。如果团队里有老版本工具链会退到 GBK 路线但要配套在仓库里加.gitattributes说明这些文件是特定编码避免被某些工具自动转换。5.2 一个不太直观的替代方案还有一种绕开编码问题的写法干脆不在.rc里写中文。把面向人的描述字段全部用英文中文只放在运行时接口里。这个做法听起来是妥协但对很多基础库来说反而是合理的——属性面板的主要消费者是系统工具和下游开发者英文描述完全够用还避免了各种编码环节的麻烦。如果确实需要中文另一个稳妥做法是把.rc里所有非 ASCII 字符写成\x转义形式。windres支持这种写法资源节里存的就是正确的宽字符不依赖输入文件的编码VALUE CompanyName, \x7f3a\x4f8b\x5de5\x4f5c\x5ba4\0可读性极差适合脚本生成不适合手写。所以实际工程里我一般是“构建时用脚本根据一份 UTF-8 的版本清单生成.rc”把编码问题收敛到一个生成器里而不是散落在手写脚本中。生成器可以放心地输出转义形式或者直接用-c 65001两条路都好走。提示改完编码相关的东西一定要重新跑一次windres再链接。.rc改了但没重新编译资源DLL 里还是旧内容这个坑每年都有人踩。用 Makefile 时确保.rc在依赖列表里用 CMake 时确认.rc在源文件列表里。6. 链接环节的三个坑比写资源更容易翻车6.1 资源.o打进了静态库然后消失了这是最隐蔽的一个坑。很多人为了工程整洁会把version.o和一堆其他目标文件一起打成静态库libmylib_objs.a然后链接 DLL 时只给这个.a。结果 DLL 编出来了资源节却没有。原因在链接器的工作机制静态库里的成员只有在“被需要”时才会被拉进最终产物。所谓被需要是指库里有符号能解决当前未定义的引用。version.o里只有资源节没有任何符号所以链接器认为它没被需要直接跳过。这不是 MinGW 的毛病所有基于 COFF/ELF 的链接器都这样。解决办法有三种按推荐程度排序一是干脆别打包.o直接作为链接输入。最简单也最不容易出错x86_64-w64-mingw32-gcc -shared -o mylib.dll mylib.o version.o二是用 whole-archive 强制拉入x86_64-w64-mingw32-gcc -shared -o mylib.dll mylib.o \ -Wl,--whole-archive libmylib_objs.a -Wl,--no-whole-archive注意--whole-archive的影响范围是它之后到--no-whole-archive之间的所有库别把不该强制拉入的库也夹在中间否则会把一堆无用代码塞进 DLL体积白涨。三是给资源.o里加一个哑符号然后从主代码里引用它。这个做法太绕除了历史遗留工程不建议新项目用。排查这个坑有个快招x86_64-w64-mingw32-objdump -h mylib.dll看节表里有没有.rsrc。没有就是资源没进链接不用再往下查了。6.2 多个.rc文件重复定义工程变大之后容易出现多个.rc一个给 DLL 主模块一个给某个子模块各自都定义了VS_VERSION_INFO。链接时两个资源节合并同名资源类型加同名 ID 就冲突了报multiple definition或者更含糊的duplicate resource。资源在 PE 里是按“类型 名称 语言”三级组织的。两个VS_VERSION_INFO如果语言块也一样就是完全重复必须二选一。如果语言块不同比如一个040904b0一个080404b0它们会作为同一个版本资源的两个语言版本共存这是合法的属性面板会根据系统语言挑一个显示。所以合并多个.rc的正确姿势是版本信息只在一个地方定义其他.rc只放图标、清单这类不冲突的资源。如果确实要拆用#include把版本块统一引到一个主脚本里避免手抄两遍。6.3 资源.o的机器架构必须匹配前面提过一句这里展开说。windres默认输出 COFF 格式但它输出的 COFF 是 32 位还是 64 位取决于这个windres本身属于哪套工具链。用i686-w64-mingw32-windres编出来的.o是 32 位格式链接 64 位 DLL 时链接器会报格式不匹配错误信息通常带i386和x86-64两个词。有些链接器版本不会直接报错而是给一个 warning 然后悄悄跳过最终现象是资源没了但构建“成功”。这比报错还难查。所以构建脚本里最好把编译器前缀做成一个变量windres也从同一个变量拼出来CROSS ? x86_64-w64-mingw32- CC : $(CROSS)gcc WINDRES : $(CROSS)windres这样切换目标平台只改一处不会出现“编译器换了、资源编译器忘了换”的低级错误。CI 里尤其要注意矩阵构建多个架构时这一步是最容易漏的。7. 验证闭环Linux 侧看到什么Windows 侧看到什么7.1 objdump 能证明的与证明不了的验证资源是否进去第一站是objdump。x86_64-w64-mingw32-objdump -h mylib.dll会列出所有节其中有.rsrc就说明资源节存在。用-p看 PE 头信息能看到 Resource Directory 的 RVA 和大小The Data Directory Entry 2 00000000 00000000 00000000 00000000 Resource Directory如果这两项都是 0说明没有资源。如果 RVA 非零进一步看节表能确认.rsrc的大小。但objdump不能解析版本资源的具体内容。它不认识VS_VERSION_INFO的结构只能告诉你“这里有资源”说不出产品名是什么、版本号是多少。这一点很多人误以为objdump -p能像readelf那样把内容都摊开实际不行。想快速看一眼有没有明显问题可以用x86_64-w64-mingw32-objdump -h mylib.dll | grep rsrc有输出就是有资源节。这是一个廉价的健康检查适合塞进 CI 的 smoke test。7.2 用 Python 精确解析版本块要真正读到字段内容最省事的工具是pefile。它能把资源目录完整走一遍把StringFileInfo里的键值对全打印出来import pefile pe pefile.PE(mylib.dll, fast_loadTrue) pe.parse_data_directories( directories[pefile.DIRECTORY_ENTRY[IMAGE_DIRECTORY_ENTRY_RESOURCE]] ) for fileinfo in pe.FileInfo: for entry in fileinfo: if entry.Key bStringFileInfo: for table in entry.StringTable: for key, value in table.entries.items(): print(f{key.decode()} {value.decode(errorsreplace)}) elif entry.Key bVarFileInfo: for var in entry.Var: print(f{var.Key.decode()} {var.entry})跑出来应该是完整的八条键值。中文如果显示成乱码说明编码环节有问题回到上一节处理。这个脚本我一般会放进仓库的tools/目录CI 里出版本包之前跑一次断言LegalCopyright非空、FileVersion等于预期值。这比人肉点属性面板靠谱得多也避免了“忘了检查就发版”的低级失误。7.3 Windows 侧的双重确认最终还是要到 Windows 上看一眼因为属性面板的渲染逻辑和解析器不完全一样某些字段在某一边能显示、另一边不一定。右键属性看“详细信息”是最直观的但更严谨的做法是用 PowerShell 读VersionInfo对象$vi (Get-Item .\mylib.dll).VersionInfo $vi | Format-List FileVersion, ProductVersion, CompanyName, LegalCopyright, FileDescription这个对象读的就是资源节字段齐全适合写进自动化验收脚本。注意FileVersion和ProductVersion这里返回的是字符串形式跟FILEVERSION整型字段是对应关系两边不一致的话会在这里暴露出来。还有一个容易忽略的验证点OriginalFilename要和实际文件名一致。如果 DLL 被重命名过属性面板上“原始文件名”会保留旧名字这是设计如此并不是 bug。但如果这个字段本身写错了某些安装包工具做文件校验时会报不匹配。所以发版前顺手核对一下这个字段值得。8. 工程化落地Makefile 与 CMake 两种写法8.1 Makefile 里的变量组织把前面所有东西收拢进 Makefile核心是让资源编译和普通编译共享同一套前缀变量同时把.rc放进依赖图CROSS ? x86_64-w64-mingw32- CC : $(CROSS)gcc WINDRES : $(CROSS)windres OBJDUMP : $(CROSS)objdump CFLAGS : -O2 -Wall -Wextra -DMYLIB_EXPORTS RCFLAGS : -O coff -c 65001 LDFLAGS : -shared -Wl,--out-implib,libmylib.dll.a VER_FILE : version.rc all: mylib.dll mylib.o: mylib.c $(CC) $(CFLAGS) -c -o $ $ version.o: $(VER_FILE) $(WINDRES) -i $ $(RCFLAGS) -o $ mylib.dll: mylib.o version.o $(CC) $(LDFLAGS) -o $ $^ $(OBJDUMP) -h $ | grep -q \.rsrc || \ (echo resource section missing exit 1)最后那行自检很关键。它把“资源是否进链接”变成一个可自动判定的条件而不是靠人肉记忆。这个思路可以推广到任何“容易漏掉但要保证存在”的构建产物上。版本号注入可以走变量覆盖make VER_MAJOR2 VER_MINOR0 VER_PATCH1 VER_BUILD7前提是.rc里用#ifndef给默认值#ifndef VER_MAJOR #define VER_MAJOR 1 #endif这样本地开发和 CI 都能用同一条构建命令CI 只需要从 tag 里解析出四段数字传给 make。8.2 CMake 处理.rc的差异CMake 对资源文件的支持是内建的只要工具链配置正确.rc会自动走CMAKE_RC_COMPILER。关键是 toolchain 文件要写全set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86_64) set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc) set(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres) set(CMAKE_FIND_ROOT_PATH /usr/x86_64-w64-mingw32) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)工程里把.rc加进源文件列表add_library(mylib SHARED mylib.c version.rc)CMake 会自动识别.rc扩展名并调用资源编译器。有一个细节要注意CMake 传给windres的参数和手写命令不完全一样它默认会加-I搜索路径、指定输出格式但不会自动加-c代码页参数。所以 UTF-8 的.rc在 CMake 下更容易出编码问题。解决办法是在 toolchain 里补一行set(CMAKE_RC_FLAGS ${CMAKE_RC_FLAGS} -c 65001)这条容易漏。我见过不止一个项目手写 Makefile 时编码正常换到 CMake 之后中文就乱了查半天才发现是这个默认参数差异。另外CMake 生成 DLL 时默认会带上--out-implib导入库名字是libmylib.dll.a位置在构建目录。如果要改名字用set_target_properties(mylib PROPERTIES IMPORTED_IMPLIB ...)或者直接ARCHIVE_OUTPUT_NAME。再补一个和 CMake 相关的小坑如果工程里同时有enable_language(RC)和自定义的CMAKE_RC_COMPILER设置顺序不对会导致编译器探测失败。稳妥做法是在 toolchain 文件里把编译器路径设好工程里不要重复设置让 CMake 自己探测。9. 几个反复出现的问题与处理办法9.1 属性面板全是 0.0.0.0这是最高频的问题。原因几乎总是“资源没进链接”。排查顺序建议按这个来第一看.rsrc节在不在命令是objdump -h。不在就往链接环节查重点看资源.o有没有出现在链接命令里、有没有被包进静态库导致被丢弃。第二.rsrc节在但版本号是 0那就看FILEVERSION是不是真的写了。有一种情况是#define展开成了空比如VER_MAJOR没定义而#ifndef又漏了预处理器把它当 0 处理。用windres -E预处理一遍看展开结果最直接。第三版本号对但字符串空看VALUE行的第二个参数有没有写\0以及字符串块的语言 ID 和Translation是否匹配。语言对不上时系统的属性面板会找不到对应语言块退回显示空白。9.2 只有中文乱码英文正常编码问题的典型症状。先确认windres有没有加-c再加对值。UTF-8 文件配-c 65001GBK 文件配-c 936配错组合会得到部分乱码。如果加了参数还是乱检查文件是否真的存成了你以为什么编码。Linux 下file -i version.rc能给出猜测的编码虽然不总是准但能排除明显的错配。还有一种可能是编辑器存了带 BOM 的 UTF-8某些windres版本会把 BOM 当内容吞进去导致第一个资源定义前面多出几个不可见字符报错位置也会偏。实在查不出来退一步用\x转义写法把中文字符串直接编码成宽字符序列绕过整个编码推断流程。可读性虽然差但确定性最高。9.3 32 位和 64 位产物混用前面提过这里给一个自查清单。切换目标架构时以下四项必须同时切项目64 位32 位编译器前缀x86_64-w64-mingw32-i686-w64-mingw32-资源编译器前缀x86_64-w64-mingw32-i686-w64-mingw32-调用约定修饰无stdcall 带N链接选项常规可能需要--kill-at表格里后两项是逻辑差异前两项是必须物理切换的。CI 里跑矩阵构建时把前缀做成矩阵变量四个地方都从同一个变量拼出来就能杜绝混用。我自己在第一次做双架构发布时踩过这个坑构建脚本里编译器用了变量windres却写死了 64 位前缀。64 位产物一切正常32 位产物资源全丢而且构建日志里没有任何报错因为那个版本的链接器只是默默跳过了格式不匹配的输入。等到用户反馈属性面板空白回头查了两天才定位到这一行。9.4 一个容易被忽略的细节版本资源与数字签名的顺序如果 DLL 后续要加数字签名版本资源必须在签名之前写好。签名是对整个 PE 文件内容做哈希再加密签完之后再改资源会让签名失效。所以构建流水线里的顺序应该是编译 → 链接资源 → 签名 → 分发。别搞反了反了之后签名验证会失败而失败提示通常只说“签名无效”不会告诉你是因为资源被改过。这条在纯 Linux 构建链里也适用只是签名那一步可能用的是跨平台的签名工具或者放到另一台机器上做。无论哪种都要保证资源是在签名前定稿的。至此从工具链选择、导出符号处理、资源脚本编写、编码处理、链接陷阱到验证与工程化整条链路就串起来了。回头看真正难的地方不在语法而在几个“静默失败”的环节资源被静态库吞掉不报错、编码不对只影响中文、架构不匹配时链接器可能跳过。把这些环节都变成可自动检查的断言比记住一堆命令更有价值。我现在做新项目时第一件事就是把.rsrc存在性检查和版本字段内容检查写进构建脚本后面改什么都不用再担心属性面板突然变空白。
