Package Details: mingw-w64-cmake 1-20

Git Clone URL: (read-only)
Package Base: mingw-w64-cmake
Description: CMake wrapper for MinGW (mingw-w64)
Upstream URL:
Licenses: GPL
Submitter: brcha
Maintainer: xantares
Last Packager: xantares
Votes: 46
Popularity: 0.719954
First Submitted: 2013-04-17 12:11
Last Updated: 2018-03-24 19:59

Required by (114)

Sources (3)

Latest Comments

xantares commented on 2018-02-07 17:29

ok, seems good

jpcima commented on 2018-02-07 01:26

The toolchain files do not define CMAKE_SYSTEM_PROCESSOR, so this variable presents to cmake as empty and cannot do architecture checks. Can you add this definition to the toolchain files?


xantares commented on 2017-08-17 15:36

Adding wine as dependency here does not make it a runtime dependency of mingw packages as mingw-w64-cmake is never a runtime dependency.

But I agree not all packages (cgal, hdf5, ...) rely on running compile checks (try_compile, ...) that use wine.
You can also override these results but it's a pain to update (see hdf5).

Martchus commented on 2017-08-16 21:02

Wouldn't it be better to make wine an optional dependency? A lot of packages using this wrapper at build time but don't require wine.

markand commented on 2016-09-12 20:19

Oh I didn't know strip could remove the debug symbols, I always thought it was for removing useless ones.

I will double check if it produces the same executable once stripped, thanks.

Martchus commented on 2016-09-11 16:52

I think xantares' explanation makes sense:
"-g -O2" makes great sense actually: when you're debugging you want your code to behave like the the release code in order to better reproduce bugs. Debug symbols are actually removed by the strip commands ... .

markand commented on 2016-09-11 14:39

Can you also remove the -g flag from the CFLAGS in the CMake script? I wonder why is it enabled globally as it's only relevant in Debug builds. Thanks.

Martchus commented on 2016-09-03 16:02

markand: I noticed the same problem with some of my own projects (qtutilities) and wasn't able to fix it yet. The problem occurred with a mingw-w64-gcc update, but actually it is CMake which messes the include paths. It is still unclear to me why this happens but I'll try your fix. If it works, I would also vote for including it here.

markand commented on 2016-09-03 15:37

After some investigation and tests with ngladitz from the #cmake channel, I figured out how to fix. We need to set CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to make it work.

Would you mind adding this to the x86_64-w64-mingw32-cmake (and same for 32 bits)


markand commented on 2016-09-02 05:11

I don't know if it's a CMake problem, but once I try to build a program that links to mingw-w64-openssl library, the include headers are broken.

This is a test project:

cmake_minimum_required(VERSION 3.5)
find_package(OpenSSL REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main OpenSSL::SSL OpenSSL::Crypto)

Compiling like this:

x86_64-w64-mingw32-cmake .

Ends with that error:

In file included from /tmp/test/main.cpp:1:0:
/usr/x86_64-w64-mingw32/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>

However, removing the last target_link_libraries builds successfully. The includes specified by cmake are defined as: -isystem /usr/x86_64-w64-mingw32/include

I could not find anything in the FindOpenSSL.cmake that use this directory.

EDIT: after some investigation, it seems that any libraries linked to the project break it. I can reproduce the same problem with FindPNG package and mingw-w64-libpng.

xantares commented on 2016-07-13 20:05

You can override the -02 flag by appending -O0, ie "-O2 -O0" are valid CFLAGS, the last (-O0) value overrides the level 2 optimization O2.

Martchus commented on 2016-07-13 19:59

Of course I know that debug symbols are stripped anyways. I was just wondering about the combination with -O2 but your explanation makes sense.

I just mentioned -g because I've read the previous discussion. Actually I want to get rid of -O2 as a workaround for the mentioned issue (see my first comment). Hence overwriting (and not just appending) would still be useful for me. Maybe there are other use cases, too. If you like, you can try to reproduce the issue (should only take 1 minute).

xantares commented on 2016-07-13 19:40

"-g -O2" makes great sense actually: when you're debugging you want your code to behave like the the release code in order to better reproduce bugs.
Debug symbols are actually removed by the strip commands so if you wanted to override flags just to disable -g it's useless.

Martchus commented on 2016-07-13 18:32

Thanks for your fast response :-)

I know appending is possible in mingw-w64-configure. If you look at the code in my repo you'll see I also added this for mingw-w64-cmake. However, it would be nice to get completely rid of some flags. That is why I'd like to introduce another environment variable for that. I think this wouldn't hurt anyone.

BTW: I also read the previous discussion about the default flags and I have to say that these are a bit strange indeed. In particular the combination of -g (which generated debugger information) and -O2 (which enables most of the available optimizations) doesn't make very much sense to me.

EDIT: kalev from #fedora-mingw just told me that the reason they chose those particular build flags is to match the build flags regular Fedora binaries use as similar as possible.

xantares commented on 2016-07-13 18:16

good idea, you can already do that in mingw-w64-configure by calling CFLAGS="-foo" ${_arch}-configure for flags to be appended to the default flags.
I'll do the same here so you could do CFLAGS="-O0" ${_arch}-cmake

Martchus commented on 2016-07-13 18:01

The default build flags should be configurable. I would propose to make the default build flags configurable via the environment variable CUSTOM_MINGW_FLAGS.

Achieving this would be very simple: mingw_flags="${CUSTOM_MINGW_FLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4}"

For consistency the changes should also be included in mingw-w64-configure.

For the full source code of the proposed changes for both packages check out my PKGBUILDs repository:

The reason I want to customize the build flags is that I the default ones are currently causing some trouble for me. In particular the compiler flag -O2 is causing page faults in the resulting application when an instance of std::stringstream is created in a shared library. As a workaround I need to use -O0 when building the shared library.
If you want to reproduce the issue, here is a small example application and library:
The commands to compile and run are also provided.
I haven't had the time yet for further investigations of the issue, eg. to check whether other classes and the i686 architecture are also affected. Hence I haven't filed a bug report yet.

xantares commented on 2016-04-03 07:36

@chenxiaolong, thanks!

chenxiaolong commented on 2016-04-03 00:45

@xantares: As an alternative to copying DLLs in, you could simply set the WINEPATH environment variable to the bin directory.

For example, I run my CMake tests with:

WINEPATH="/usr/i686-w64-mingw32/bin;$(pwd)/libmblog" ctest -VV

Something similar should also work in your script.

Cloudef commented on 2015-12-10 00:16


- You make good point of the native cflags. I did not consider those. It's weird fedora uses those weird flags as well (such as forcing exceptions, defining ssp parameter without enabling it, and just blatantly forcing -O2, -g, -Wall and -pipe, which are all situational options)

- Yeah I sort of assumed this. I'm not sure what implications with moving the variables to the toolchain file would be though. In theory it should work the same, just without the warnings.

Anyhow, thanks for your explanations.

xantares commented on 2015-12-08 13:10

xantares commented on 2015-12-08 13:07


- Native flags from makepkg should not be read, the option !buildflags should be set in every mingw package, as you may have something like march=... which is invalid for cross-compiling
I'm no expert in what those flags are and what they should be, I wanted to standardize the way mingw packages are built (see also mingw-w64-configure).
I just took them from Fedora, and maybe they even changed.

- I may have put them here because I had several packages relying on this behavior.
I also use the toolchain files for development, and setting these variables in the toolchain would maybe be more annoying than the cmake unused warning.


Cloudef commented on 2015-12-07 13:50


I usually expect packages on arch / aur to be close to upstream / vanilla as possible so the CFLAGS and BUILD_SHARED_LIBS came as bit of surprise.

For example the CFLAGS looks quite similar to that of /etc/makepkg.conf default ones, but cmake _does_ read CFLAGS and CXXFLAGS first time cmake is ran, so it will actually work with /etc/makepkg.conf and you don't have to set them in the script, to avoid surprises for some. The fexceptions also makes no sense in the flags. nor the ssp buffer size without enabling ssp. -Wp, (while correct) is unneccessary. Also they set some defaults like -O2 with -g, this is all quite undesirable for people who simply assume it just handles cross-compilation using mingw but doesn't touch anything else.

For BUILD_SHARED_LIBS, while I agree there are many horrible cmake projects and they do weird things regarding this global variable, or weird things in general. I think these hacks should be handled at their respective PKGBUILDs.


These variables also aren't standard CMake variables, apart from CMAKE_INSTALL_LIBDIR, that is actually provided by GNUInstallDirs cmake module. Others are hacks by project developers who dint bother reading CMake documentation and find about GNUInstallDirs, or the project was done with very early before GNUInstallDirs was available.

While it's bit dirty, I don't propose removal of those variables. But you might be able to put them into toolchain file instead and avoid CMake warning about unused manually specified variables.

I think this package is highly useful and really nice, but these 2 certainly were surprising to me. Especially since I actually used this in development instead of building AUR packages.

xantares commented on 2015-12-07 12:38

- these are CFLAGS that go well for mingw, I dont know the meaning of all flags, but you need at least to override native flags that would be invalid here
- BUILD_SHARED_LIBS is set to build shared libs by default, but not every packages honor this canonical way of deciding static/shared, some use another name or set the default value to OFF

Cloudef commented on 2015-12-07 09:46

Why do you specify CFLAGS and force BUILD_SHARED_LIBS in the wrapper?

Schala commented on 2013-05-08 21:49

Oooh I didn't see that.

brcha commented on 2013-04-17 15:28

Why? What's the difference? The names are symlinked. I can make the scripts be *-w64-mingw32-cmake and symlinks mingw{32,64}-cmake, but I see no difference between the two combinations.

Schala commented on 2013-04-17 15:25

Could you rename the wrapper scripts to (i686/x86_64)-w64-mingw32? It helps. Thanks