2021年如何通过MingW64构建Linux工具？含wget2编译相关问题

问题解答 #

1. 安装错误排查与依赖确认 #

你遇到的./configure无法运行的问题一般不是MinGW工具链安装错误，而是缺少配套的构建环境组件。你可以按以下标准核对所需安装内容：

• 必须安装完整的MSYS2基础环境，包含bash、autoconf、automake、make、libtool等构建工具，./configure是类Unix shell脚本，无法在纯Windows命令行环境下直接运行
• 对照wget2的构建要求，提前安装所有对应架构的依赖库，所有依赖的编译参数、线程模型、运行时类型必须和你使用的x86_64-8.1.0-win32-seh-rt_v6-rev0工具链完全匹配，不能混用不同版本的预编译库

2. 工具链版本复用规则 #

不需要每构建一个应用就安装新的预设版本，只要当前工具链满足以下条件就可以通用：

• 工具链架构和目标程序架构一致（当前x86_64版本仅能构建64位程序）
• GCC版本支持目标程序用到的C/C++语法特性
• 线程模型、运行时类型和所有依赖库的编译参数匹配
  只要符合上述要求，同一个工具链可以构建多个不同的应用，无需重复安装。

3. wget2构建依赖处理方案 #

你可以通过以下方式降低依赖处理的复杂度：

• 优先使用MSYS2官方源中的预编译依赖包，直接安装对应架构的依赖库，不需要手动逐个编译
• 执行./configure时通过--disable-xxx参数关闭你不需要的可选功能，减少需要安装的依赖数量，例如不需要HTTP/2支持即可关闭对应的nghttp2依赖
• 手动编译依赖时遵循从底层到上层的顺序：先编译zlib、libiconv等基础库，再编译libssl、libpsl等上层依赖，最后编译wget2本身，所有依赖统一指定相同的安装前缀，避免链接时找不到库的问题

4. 编译体验差的原因 #

这类问题不是单一设计导致的，是多方面因素共同作用的结果：

• 多数开源命令行工具优先适配Linux/Unix环境，对Windows原生编译的适配程度较低，构建逻辑没有兼容Windows平台的路径、库命名等差异
• Windows平台没有统一的开源软件包管理体系，无法像Linux一样通过包管理器自动安装所有编译依赖，需要用户手动处理所有依赖的版本、参数匹配问题
• MinGW工具链本身存在碎片化问题，不同版本、线程模型、运行时的工具链互不兼容，参数稍有不匹配就会出现编译、链接错误

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