搞Windows下的GMP配置这件事说难不难说简单也真不简单。GMPGNU Multiple Precision Arithmetic Library是做高精度计算绕不开的库RSA、ECC、大数乘法这些场景基本都在用它。问题是这货是典型的Unix思维产物configure、make这一套流程在Windows命令行里根本跑不起来所以网上教程虽然多但大部分都停留在“理论上应该怎么操作”这种层面真正从零讲到能被Visual Studio 2019调用的很少。我这篇就以gmp-6.2.0 MSYS VS2019这个组合为例把编译、链接到跑通demo的整个链路完整走一遍所有参数都会说明为什么这么写踩过的坑也都记录下来给后面折腾这个环境的朋友省点时间。1. 环境准备与整体思路1.1 为什么Windows下配置GMP这么麻烦GMP的构建体系基本是为类Unix环境设计的官方没有直接提供Windows可用的二进制包因为Windows下不同的编译链MSVC、MinGW、Cygwin对C库的依赖、符号修饰规则、结构体对齐方式都不一样没法一个包通吃。核心矛盾在于GMP的构建脚本依赖Unix Shell、make、m4、gcc这些工具而它们在Windows原生环境里要么没有要么行为和Unix版本有差异。你如果在cmd里直接敲./configure大概率会得到“不是内部或外部命令”的错误所以第一步就是搭一个能在Windows里跑Unix脚本的环境MSYS就是干这个用的。我在很多帖子里看到有人纠结“为什么不用Visual Studio直接打开源码编译”原因是GMP的构建过程不是单纯编译几个.c文件那么简单它要根据平台特性生成config.h还要运行一系列测试程序来探测当前CPU支持哪些指令集比如BMI2、ADX这些VC的工程文件根本无法覆盖这种动态配置流程所以必须走configure这条路线。1.2 方案选型自己编译还是找预编译包在动工之前先想清楚一个问题是老老实实自己编译还是直接拿别人编译好的成果物如果你运气好能找到和你系统位数、编译环境匹配的GMP二进制包确实可以省掉后面大半的折腾。但现实是网上能找到的所谓“Windows版GMP”大多是Cygwin或MSYS2下编译出来的依赖关系非常混乱有的你拿过来链接时才发现它内部依赖了一堆Cygwin的DLL程序跑到别人机器上根本起不来。另外还有一个我自己试过的路vcpkg。在vcpkg里执行vcpkg install gmp:x64-windows确实能装而且装的是MSVC版本和VS2019无缝衔接。如果你只追求“能用”vcpkg是当前最省心的方案。但vcpkg的GMP实例在部分场景下性能表现不如MinGW编译的版本原因后面会说而且如果你需要定制编译参数比如开启C接口、裁剪不需要的功能它并不灵活。我这篇还是完整讲一遍源码编译路线因为这条路走通之后你能清清楚楚知道GMP在Windows上到底是怎么运作的以后遇到链接错误也能准确判断问题出在哪而不只是靠试错。2. 搭建编译环境MSYS与MinGW工具链2.1 下载安装MSYS环境严格来说标题里的“MSYS”指的是Minimal System它是MinGW项目附带的一个类Unix Shell环境。但它和现在很多人用的MSYS2一个独立的发行版不是同一个东西两者在包管理和工具链更新频率上有很大差别。如果你用的是经典的MinGW安装器mingw-get里面会有一个MSYS组件路径一般在C:\MinGW\msys\1.0双击msys.bat就能进入bash环境。这个环境对应的是32位的MinGW GCC工具链。如果你像我一样在2024年才第一次配这个环境我更推荐直接上MSYS2。原因很简单MSYS2的包管理系统是pacman一条命令就能装gcc、make、m4这些不用像老MSYS那样挨个组件点选而且它可以同时提供mingw32和mingw64两套工具链。无论使用哪个MSYS核心目标是同一个获得一个能在Windows中运行的Bash Shell并且这个Shell里能调用gcc、make、ar、ranlib、m4这些GNU工具。下面以我实际使用的MSYS2为例老MSYS的用法完全一样只是包管理器不同安装MSYS2默认安装在C:\msys64。安装后打开MSYS2 MINGW64这个终端注意不是MSYS2 MSYS那个终端后者默认使用MSYS工具链编译出来的东西依赖msys-2.0.dll不适合给VS用先跑一遍更新pacman -Syu然后安装需要的工具链和依赖pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-make mingw-w64-x86_64-m4 diffutils make这里有个需要注意的地方mingw-w64-x86_64-make安装的make二进制名是mingw32-make.exe它和MSYS自带的make.exe依赖msys运行时是两个不同的东西。为了省事我建议在MSYS2终端里使用make.exe也就是MSYS推荐的GNU make它虽然有MSYS运行时依赖但只在编译GMP时用最终产物gmp是纯MinGW的不影响交付。装完后确认一下gcc --version make --version m4 --version能看到版本信息说明基本环境已经是好的了。2.2 编译位数的选择32位还是64位这个决定影响了后面所有参数必须在开始前想清楚。如果你是在Visual Studio 2019里创建了x64项目那么GMP必须编译成64位版本否则链接器会直接报架构不匹配类似LNK1112: module machine type x86 conflicts with target machine type x64。在MSYS2里进入MSYS2 MINGW64终端此时gcc -dumpmachine输出应该是x86_64-w64-mingw32这表示我们正在用64位MinGW工具链。在老MSYS环境下默认是32位gcc需要单独安装64位编译器并用环境变量切换。老MSYS配64位编译器比较麻烦这也是我在实际过程中选择MSYS2的重要原因。如果你手头的环境是老MSYS建议还是尽早迁移到MSYS2省下的时间足够把GMP编译好几遍。另外要注意MSYS2的MINGW64终端会把/mingw64/bin放到PATH前面这是对的。验证的时候可以在bash里执行where gcc确认指向的是C:\msys64\mingw64\bin\gcc.exe而不是MSYS自带的那个。3. GMP 6.2.0编译实战3.1 下载源码与解压GMP 6.2.0可以从官网下载文件名一般叫gmp-6.2.0.tar.bz2或gmp-6.2.0.tar.lz。我建议下载.tar.bz2格式Windows下的解压工具兼容性更好.tar.lz需要额外的lzip支持。在MSYS2终端里可以用curl或wget下载cd /c/msys64/home/你的用户名 wget https://gmplib.org/download/gmp/gmp-6.2.0.tar.bz2 tar -xjf gmp-6.2.0.tar.bz2 cd gmp-6.2.0这里说明一下为什么要把源码放在home目录下MSYS2的home目录映射到C:\msys64\home\用户名这个目录读取速度比跨盘符快而且目录路径里没有空格的概率更大。很多人后面configure报各种诡异错误其实就是因为源码放在了带空格的路径下比如C:\Program Files\...。不过如果你是用Windows资源管理器下载的源码也没关系在MSYS2里直接访问/c/Users/xxx/Downloads/gmp-6.2.0然后解压即可只是注意路径别带空格。3.2 configure参数每一个都别省进入源码目录后重点就是configure这一步。不同教程的写法五花八门我给出一个我认为最适合给VS2019提供库文件的组合./configure --enable-cxx --disable-static --enable-shared --prefix/c/gmp-install逐个解释--enable-cxx编译C接口也就是gmpxx.h和libgmpxx。如果你只用C接口这个参数可以不写但加上也不会有什么坏处一般建议加上因为后期你很可能遇到需要mpz_class这种C封装的场景。--disable-static --enable-shared让GMP只生成DLL和对应的导入库。这是关键中的关键后面章节我会详细解释为什么不要在这里图省事生成静态库。--prefix/c/gmp-install指定安装目录。/c/gmp-install对应Windows路径C:\gmp-install安装在C盘根目录下路径短、好找、不存在权限问题。我遇到过有的人在configure时加--buildx86_64-w64-mingw32和--hostx86_64-w64-mingw32来强制指定构建目标这在交叉编译场景下是必须的但如果你用的是MSYS2的MINGW64终端工具链本身就是目标平台不加也能自动检测正确。当然加了也没问题保险起见可以加上./configure --buildx86_64-w64-mingw32 --hostx86_64-w64-mingw32 --enable-cxx --disable-static --enable-shared --prefix/c/gmp-installconfigure脚本会运行一连串测试程序来检测CPU特性、编译器行为耗时大概几分钟。期间如果报错说找不到m4回到上一章安装m4即可如果报C compiler cannot create executables通常是工具链有问题检查一下gcc是否能编译一个简单的hello world。3.3 make、make check与make installconfigure成功后目录下会生成Makefile。接下来make -j8-j8表示8线程并行编译如果CPU核心少就改成-j4。GMP源码规模不大几秒钟到几十秒就能编完。编译完成以后我强烈建议先跑一下自检make check这一步会编译并运行大量测试用例验证GMP是否正常工作。之前我在某个老版本MSYS环境下遇到过tests/mpz/t-mul.c里的测试通不过的情况最后发现是工具链的浮点寄存器滥用导致的属于工具链bug。如果你遇到make check有失败项建议先不要急着往下走排查清楚了再继续否则Debug阶段出现计算错误你会怀疑人生的。确认测试通过后make install这一步会把头文件、库文件统一拷贝到/c/gmp-install目录下目录结构大概是C:\gmp-install\include\gmp.hC:\gmp-install\include\gmpxx.hC:\gmp-install\lib\libgmp.dll.aC:\gmp-install\lib\libgmpxx.dll.aC:\gmp-install\bin\libgmp-10.dllC:\gmp-install\bin\libgmpxx-4.dll这里面最值得我们关注的是DLL的命名。GMP从第5版开始Windows下导出的DLL就叫libgmp-10.dll10表示库的ABI版本号。以后如果你看到别的教程里写libgmp-3.dll或者libgmp.dll那都是老版本或者特殊定制的。安装完成后可以顺手把C:\gmp-install\bin加到系统PATH里或者把两个DLL复制到C:\Windows\System32不推荐但确实有人这么干。更规范的做法是后面在VS工程里把DLL放到exe同目录这样不会污染系统。4. 让Visual Studio 2019接上GMP4.1 理解MinGW产出物静态库、动态库和导入库在VS里配置引用路径之前先花点时间搞清楚我们在第3章究竟生成了哪些文件每个文件是干什么用的因为很多人就是在这一步把文件名搞混的。MinGW的gcc编译器在生成动态库时会同时生成一个导入库import library文件名通常叫libgmp.dll.a。这个导入库看起来像是静态库但实际上里面没有真正的代码只有符号表告诉链接器“这些函数定义在libgmp-10.dll里”。VS的link.exe能够直接识别MinGW生成的.dll.a格式导入库这一点比较坑但确实可用。那为什么不推荐用libgmp.a静态库呢问题在于MinGW GCC和MSVC的C运行时库不是同一个。GMP源码使用了很多底层的编译内置函数MinGW静态链接时会把相关代码打包进静态库里这部分代码依赖MinGW的运行时初始化比如__main、_pei386_runtime_relocator这些当你用MSVC的链接器去链接这个静态库时这些符号要么缺失、要么跟MSVC的运行时库冲突。表现为各种LNK2019 unresolved external symbol __main或者LNK2038 RuntimeLibrary mismatch。所以结论很明确在给VS提供GMP时一定要用动态库。你程序里链接的是导入库libgmp.dll.a运行时依赖libgmp-10.dll这样MSVC的运行时和MinGW的运行时各管各的互不干扰。4.2 VS2019项目属性配置打开Visual Studio 2019创建一个C空项目然后打开项目属性右键项目 - 属性或者用快捷键AltEnter。首先确认右上角的解决方案配置是Release x64或者Debug x64注意和GMP编译位数保持一致这里用64位所以不能选x86。依次配置C/C - 常规 - 附加包含目录添加C:\gmp-install\include链接器 - 常规 - 附加库目录添加C:\gmp-install\lib链接器 - 输入 - 附加依赖项添加libgmp.dll.a和libgmpxx.dll.a如果你用到了C接口C/C - 预处理器 - 预处理器定义添加__GMP_LIBGMP_DLL这个后面出问题的时候会讲加上属于保险这一步我觉得有必要展开说下__GMP_LIBGMP_DLL这个宏。在gmp.h头文件里函数声明是带__GMP_DECLSPEC修饰符的#if defined (__GMP_LIBGMP_DLL) #if defined (__GMP_IMPORT) #define __GMP_DECLSPEC __declspec(dllimport) #else #define __GMP_DECLSPEC __declspec(dllexport) #endif #else #define __GMP_DECLSPEC #endif如果不定义__GMP_LIBGMP_DLL函数声明不带dllimportMSVC在编译时不知道函数在DLL里但它依然可以通过导入库解析符号所以实际上也能链接成功。区别在于定义了dllimport之后调用DLL函数的代码会更高效省一次间接跳转而且在某些文件内使用全局变量时不会出错。GMP的公共变量虽然少但保不齐你哪天用到了所以建议提前定义好。配置完成后点确定关闭窗口然后验证路径是否生效在源文件里写代码时如果#include gmp.h能正常打开头文件说明包含目录没问题如果报找不到gmp.h多半是路径写错了或者写的是#include gmp.h而VS当前的工作目录不对。4.3 写一个最小验证程序跑通配置完成后不要一上来就写大数运算的复杂逻辑先用一个最小程序验证链路是否通。C语言版示例#include stdio.h #include gmp.h int main() { mpz_t a, b, sum; mpz_init(a); mpz_init(b); mpz_init(sum); mpz_set_str(a, 123456789012345678901234567890, 10); mpz_set_str(b, 987654321098765432109876543210, 10); mpz_add(sum, a, b); gmp_printf(sum %Zd\n, sum); mpz_clear(a); mpz_clear(b); mpz_clear(sum); return 0; }如果你开启了--enable-cxx并且添加了libgmpxx.dll.a依赖也可以试试C版本#include iostream #include gmpxx.h int main() { mpz_class a(123456789012345678901234567890); mpz_class b(987654321098765432109876543210); mpz_class c a b; std::cout c std::endl; return 0; }编译第一个C语言版本时如果你用的是.c文件VS默认用C编译器编译GMP的gmp.h是用C/C双语法写的不会有问题。如果是C工程记得把源文件后缀设成.cpp。运行程序之前最关键的一步是把libgmp-10.dll和libgmpxx-4.dll放到可执行文件所在目录。如果你没放运行时会弹窗报libgmp-10.dll not found这个错误和第3章里生成的DLL文件路径没有关系它只会从以下三个地方找DLLexe所在目录、系统PATH环境变量、系统目录。所以在VS里按F5调试前建议把两个DLL复制到项目x64\Release目录下或者通过VS的“调试 - 环境”设置PATHPATHC:\gmp-install\bin;%PATH%这个设置只在调试会话中生效比较干净适合不想手动复制DLL的情况。配置到这里你的VS项目已经能正常调用GMP做任意精度运算了。可以先跑两个经验证的大数乘法比如计算100!用GMP的半行代码就能输出一个158位的整数配合亲手编译的库输出结果的时候那种成就感还是挺强的。5. 常见问题速查与避坑实录我整理了几个在这个配置链路里最常遇到的问题按阶段分类方便你对照排查。5.1 编译期问题记录configure: error: No usable m4 in $PATH这个几乎人人都见过。解决办法是安装m4pacman -S m4老MSYS下可能要检查是否漏装了MSYS的m4组件。configure: error: C compiler cannot create executables先单独验证gcc能不能编译echo int main(){return 0;} test.c gcc test.c -o test.exe如果这一步都不通过说明MSYS2的MINGW64环境没有激活完整。最常见的错误是打开了MSYS2 MSYS终端而不是MSYS2 MINGW64终端导致PATH里没有MinGW的gcc。切换到MINGW64终端再试。make: ar: command not found这说明ar工具不在PATH中。安装binutils或mingw-w64-x86_64-binutilspacman -S mingw-w64-x86_64-binutils编译时遇到-marchnative不认识GMP 6.2.0的configure会根据CPU探测结果设置-march参数但某些MinGW版本对-marchnative支持不好。这个情况下可以显式指定CFLAGS覆盖./configure CFLAGS-O2 -m64 --hostx86_64-w64-mingw32 ...不过这个坑在新版MSYS2里较少出现因为新版gcc对-marchnative的支持已经很完善了。5.2 链接与运行期问题记录LNK2019: unresolved external symbol __gmpz_add这个错误表明链接器找不到GMP的符号最直接的原因是附加依赖项没配置好或者导入库路径没对上。检查项按顺序排查附加依赖项是否写的是libgmp.dll.a而不是gmp.lib附加库目录是否指向含有libgmp.dll.a的文件夹项目是x64还是x86GMP编译目标是否匹配注意一点MinGW的导入库文件名是libgmp.dll.aVS的链接器完全支持这个格式不需要转成.lib。网上有些教程说“需要把.dll.a复制成.lib”这是多此一举VS可以直接处理。LNK2038: mismatch detected for RuntimeLibrary出现这个错误常见于错误链接了MinGW生成的静态库libgmp.a。之前说过静态库内部依赖MinGW运行时和MSVC的/MT、/MD模式对不上。解决办法只有一个回去重新编译GMP使用--disable-static --enable-shared动态库方案。如果你真的必须用静态库那只能改用vcpkg或者找纯MSVC编译的GMP替代品这个不在本文的讨论范围内。运行时弹窗libgmp-10.dll not found当你用F5调试或者双击exe时系统找不到DLL。解决方法已经说过要么复制DLL到exe目录要么设置调试环境PATH。我更推荐复制DLL到exe目录因为这样程序发布的时候只要带着DLL一起分发就行不依赖用户机器的PATH配置。5.3 加餐改用MSYS2的替代方案如果看了前文的老MSYS还是觉得折腾那就直接换MSYS2吧。它在处理GMP编译时的体验比老MSYS好太多了原因是包管理系统成熟一条命令装完所有依赖mingw-w64工具链更新及时编译GMP几乎不会遇到老工具链的坑自带64位编译器支持不需要手动切环境变量MSYS2下编译GMP还有一个更快的路线用pacman直接安装预编译的GMP和对应的开发文件pacman -S mingw-w64-x86_64-gmp装完以后头文件和库文件分别在C:\msys64\mingw64\include和C:\msys64\mingw64\lib下VS里把这两个目录加到包含目录和库目录附加依赖项填libgmp.dll.a和libgmpxx.dll.a一样能用。唯一的风险是pacman的GMP版本更新会比你手动编译的版本新一些遇到API变动时可能和旧代码不兼容。不过对于6.x系列API基本稳定这个风险几乎可以忽略。最后再分享一个小技巧整个流程走通后我个人的使用习惯是把GMP的DLL固定放在工程目录的thirdparty\gmp\bin文件夹里然后在项目属性里通过$(SolutionDir)宏来引用头文件和导入库包含目录$(SolutionDir)thirdparty\gmp\include库目录$(SolutionDir)thirdparty\gmp\libDLL复制到$(SolutionDir)x64\$(Configuration)\目录下这样做的效果是整个项目的GMP依赖是自包含的换一台机器clone下来不用改任何配置就能编译运行。如果你打算长期把GMP用在多个项目里我非常推荐用这种方式管理比把DLL丢进System32或者全局PATH要干净得多。最后再提醒一句如果你在编译过程中遇到我上边没有列到的错误别急着怀疑GMP出了问题先看一眼config.log里最后的报错信息绝大多数情况下问题都在工具链路径、环境变量或者架构不匹配上。遇到具体报错截图丢到搜索引擎里加上“MSYS”和“VS2019”两个关键词基本都能找到对应的解决办法。