Windows交叉编译Linux程序：使用MinGW或Cygwin

说实话，我第一次在Windows上编译Linux程序时，心里是有点打鼓的。那时候我刚从嵌入式裸机开发转到Linux应用开发，手头只有一台Windows笔记本，却要为一个ARM Linux目标板编译程序。嗯，后来我发现，这事儿其实没那么玄乎——关键就是选对工具链，然后告诉CMake：「嘿，我这是在给Linux干活。」

为什么要在Windows上编译Linux程序？

你可能觉得奇怪：直接在Linux上编译不就好了？但现实工作中，很多团队是这样的——开发机是Windows，部署环境是Linux。比如我参与过的一个工业控制项目，客户要求所有开发都在Windows上进行，但最终程序要跑在Ubuntu服务器上。你想想看，总不能每次改一行代码都远程登录Linux服务器去编译吧？

这时候，交叉编译就派上用场了。说白了，就是在Windows上生成Linux可执行文件。而CMake配合合适的工具链文件，能让这件事变得相当优雅。

两种主流方案：MinGW vs Cygwin

我个人习惯把这两个方案比作「轻量级选手」和「重量级选手」。它们都能让你在Windows上编译出Linux程序，但思路完全不同。

特性	MinGW-w64	Cygwin
本质	原生Windows程序，直接调用Windows API	模拟POSIX环境，提供Linux-like API
生成的可执行文件	Windows PE格式（.exe）	依赖cygwin1.dll，也可生成Linux ELF
交叉编译Linux目标	需要交叉工具链（如x86_64-w64-mingw32-）	安装交叉编译包后可直接编译
性能	接近原生Windows性能	有额外抽象层，略慢
兼容性	对Linux系统调用支持有限	更接近真实Linux环境

我在项目中遇到过这样一个坑：用MinGW编译一个使用了大量POSIX线程和信号量的程序，结果发现MinGW的pthread实现并不完整，某些API行为跟Linux原生不一样。后来换成Cygwin的交叉编译方案，问题就解决了。所以我的建议是：如果你的程序大量依赖Linux特有的系统调用，优先考虑Cygwin；如果只是简单的控制台程序或网络服务，MinGW完全够用。

设置CMAKE_SYSTEM_NAME为Linux

无论你选哪种工具链，核心步骤都是一样的——在CMake工具链文件中告诉系统：「目标平台是Linux」。这个关键变量就是CMAKE_SYSTEM_NAME。

来看一个典型的工具链文件，我以MinGW-w64的交叉编译为例：

# toolchain-linux-from-windows.cmake
# 目标系统是Linux
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

# 指定交叉编译器
set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)

# 指定sysroot（如果有的话）
set(CMAKE_SYSROOT /path/to/linux-sysroot)

# 查找工具链中的其他程序
set(CMAKE_FIND_ROOT_PATH /path/to/linux-sysroot)

# 搜索策略：只在目标系统中查找库和头文件
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

这里有个细节我想强调一下：CMAKE_FIND_ROOT_PATH_MODE_*这四个变量。我曾经因为没设置它们，导致CMake在Windows上找到了本地的头文件，编译出来的程序链接了Windows的库——那当然跑不了。你想想看，交叉编译最怕的就是「找错东西」。所以我的习惯是：一律设为ONLY，只在sysroot里找。

使用Cygwin的交叉编译方案

如果你选择Cygwin，工具链文件会稍有不同。Cygwin的交叉编译器通常叫x86_64-pc-linux-gnu-gcc之类的名字。安装时记得选上交叉编译包：

# 在Cygwin安装程序中搜索并安装：
# mingw64-x86_64-gcc-core
# mingw64-x86_64-gcc-g++
# 或者直接安装完整的交叉编译工具链

对应的工具链文件：

# toolchain-cygwin-linux.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

# Cygwin下的交叉编译器路径
set(CMAKE_C_COMPILER /usr/bin/x86_64-pc-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-pc-linux-gnu-g++)

# Cygwin的sysroot通常在交叉编译器目录下
set(CMAKE_SYSROOT /usr/x86_64-pc-linux-gnu/sys-root)

set(CMAKE_FIND_ROOT_PATH /usr/x86_64-pc-linux-gnu/sys-root)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

编译与测试

写好工具链文件后，使用方式跟其他交叉编译一样：

mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../toolchain-linux-from-windows.cmake
make

编译出来的可执行文件是ELF格式的，你可以用file命令验证：

$ file my_program
my_program: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped

看到「for GNU/Linux」就对了。然后把这个文件丢到Linux机器上，直接运行即可。

避坑指南

我总结几个常见的坑，都是我在项目中踩过的：

• 路径分隔符问题：Windows用反斜杠\，Linux用正斜杠/。在工具链文件中，尽量用正斜杠，或者用CMake的file(TO_CMAKE_PATH)转换。
• 动态链接库路径：交叉编译出来的程序，运行时需要对应的Linux动态库。要么静态链接，要么把库文件一起部署到目标机器上。
• 系统调用差异：即使你设置了CMAKE_SYSTEM_NAME为Linux，某些库的检测行为仍然可能受Windows环境的影响。比如check_function_exists可能会误判。
• 换行符问题：Windows的\r\n和Linux的\n。如果你的代码中有读取配置文件的逻辑，注意处理换行符差异。

核心逻辑流程图

下面这张图展示了整个流程的核心逻辑，从Windows开发环境到生成Linux可执行文件：

从图上可以看得很清楚：整个流程就是从Windows环境出发，通过工具链文件告诉CMake「目标系统是Linux」，然后CMake自动选择交叉编译器，最终生成ELF格式的可执行文件。每一步都很关键，但最核心的还是那个CMAKE_SYSTEM_NAME的设置——它就像一把钥匙，打开了交叉编译的大门。

---

公众号:蓝海资料掘金营，微信deep3321