Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib"

I submitted this bug to Capstone directly but I figured it'd be useful to post it here too. The IS_MINGW check in the Makefile for Capstone fails under MSYS2 MinGW-w64 because cc --version doesn't have mingw in the output anymore:

$ whereis cc
cc: /mingw64/bin/cc.exe

$ cc --version
cc.exe (Rev2, Built by MSYS2 project) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Really simple patch:

diff --git "a/Makefile" "b/Makefile"
index 063f50db..1d9f042e 100644
--- "a/Makefile"
+++ "b/Makefile"
@@ -288,7 +288,7 @@ CFLAGS := $(CFLAGS:-fPIC=)
 # On Windows we need the shared library to be executable
 else
 # mingw?
-IS_MINGW := $(shell $(CC) --version | grep -i mingw | wc -l)
+IS_MINGW := $(shell $(CC) --version | grep -i msys2 | wc -l)
 ifeq ($(IS_MINGW),1)
 EXT = dll
 AR_EXT = lib

NB that patch will break Linux based Mingw builds, as they don't include "mys2" in their output from gcc, so it would need to match both.



This change needs to go in via the capstone project. capstone is just an unmodified "submodule" in QEMU - we do not include any QEMU-only changes here.

Re-opened, since although the fix needs to be done in capstone, QEMU also needs a commit to actually update the submodule hash to pull in the fix.

I did submit a bug already to Capstone proper on their GitHub. Thanks for the heads-up about it needing to cover both cases for cross-compilers!

https://github.com/aquynh/capstone/issues/1464 is the upstream bug -- thanks for reporting it there.


The fix in upstream capstone has been merged: https://github.com/aquynh/capstone/commit/29893c63e34ee21846744d02c396ae3c801b936b

I am still running into this issue when compiling QEMU on Windows using MSYS2. I can manually apply the fix per the Capstone commit above and compile just fine.

For moving forward, how should this be handled in the codebase to get the MSYS2 build cleanly working? I imagine wholesale pulling the latest Capstone may break quite a bit. Is it possible to cherry-pick this one change into the submodule?

As far as I can see we're using a capstone version now that contains the commit with the fix, so I'm closing this bug. If you are still having problems, please open again or file a new bug ticket.