Building QEMU for Windows with MSYS2: Hurdles and Fixes
An in-depth look at building AQEMU 1.6.0 for Windows x64 and ARM64 using MSYS2, resolving carriage returns, missing patch tools, and named pipe quirks.
Stock photo for illustration only, not from the actual event
- Most AQEMU Windows build challenges stem from build scripts rather than actual code bugs.
- Windows named pipe implementation required a custom QEMU patch to avoid boot blockages.
- Mixed PATH environments in MSYS2 can silently break Git and OpenSSL dependency cloning.
- Version 1.6.0 successfully enables WHPX hardware acceleration for ARM64 Snapdragon hosts.
Most of the development effort on AQEMU, a Qt front-end for QEMU on Windows (x64 and ARM64) and Linux, does not lie within the graphical user interface. Instead, it is heavily concentrated in the scripts responsible for building QEMU itself using MSYS2 and packaging it for the Microsoft Store. Back in October, a single small feature cost an entire day of troubleshooting, where every obstacle was a Windows build quirk rather than a code defect.
The objective for the 1.6.0 file copy feature was to allow standard virtual machines to expose a QEMU guest-agent port. This enables AQEMU to seamlessly transfer file paths in and out once qemu-guest-agent runs inside the guest OS. On Linux, this is a straightforward Unix socket, but Windows required a named pipe approach.
Stock photo for illustration only, not from the actual event
The initial attempt broke Windows guests entirely. QEMU bound the pipe path as if it were a Unix socket, terminated execution with a network down error, and prevented the virtual machine from starting. The quick workaround was launching Windows VMs without the guest-agent pipe to keep other components unblocked during investigation.
Integrating MSYS2 into automated Windows build pipelines frequently introduces friction due to path translation mismatches, line-ending discrepancies, and tool shadowing between native Windows environments and Unix-like subsystems.
The correct solution involved applying a minor QEMU patch named third_party/patches/0001-win-lazy-named-pipe.patch so that QEMU listens on the Windows pipe immediately without stalling for an active client connection. However, the patch command was entirely missing from the build shell, causing the step to silently do nothing.
- Switched from the missing patch tool to git apply
- Addressed line-ending mismatches caused by Git for Windows checking out CRLF sources
- Rewrote target QEMU source files as LF explicitly before invoking git apply
During the same week, another dependency cloning task failed silently. MinGW OpenSSL libraries located on the system PATH caused git-remote-https to abort, leaving behind an empty directory while the build system continued happily compiling nothing. Switching exclusively to MSYS's native git utility resolved the issue.
"If you build anything with MSYS2 and a mixed PATH , check which git and which OpenSSL you're really getting."
Chronic Engineering
Furthermore, the build scripts were patched to address an oversight where the Windows on Arm QEMU target skipped WHPX acceleration, forcing Snapdragon guests to fall back to the slower TCG software emulator despite QEMU 11 supporting the ARM WHPX backend. Version 1.6.0 now properly enables WHPX on ARM64 when host support is verified.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment