Package Details: mingw-w64-cmake 1-35

Git Clone URL: (read-only, click to copy)
Package Base: mingw-w64-cmake
Description: CMake wrapper for MinGW (mingw-w64)
Upstream URL:
Licenses: GPL
Submitter: brcha
Maintainer: xantares
Last Packager: xantares
Votes: 51
Popularity: 0.76
First Submitted: 2013-04-17 12:11
Last Updated: 2020-11-07 21:45

Dependencies (5)

Required by (215)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

hhromic commented on 2019-12-01 11:42

Hi all, I noticed that the standard NDEBUG define for disabling debug and assertions is not being set by this CMake wrapper when the build type is Release (expected behaviour).

I went to debug a bit and the wrapper is doing this:


Which seems to be forcing specific C/CXX/LD flags to the Release build type and the C/CXX flags do not indeed contain -DNDEBUG.

This seems to be breaking the expected behaviour done by upstream CMake. For instance for the GNU compilers:

Isn't CMake able to automatically pick (and add instead of replace) all the $CFLAGS, $CXXFLAGS, $LDFLAGS from the environment without the need to explicitly set them using CMAKE_*_FLAGS variables?

I tested removing these variables in the wrapper and CMake correctly picked the defined e.g. default_mingw_compiler_flags and correctly kept the -DNDEBUG and -O3 flags for Release in the resulting CFLAGS and CXXFLAGS for the project I'm working on:

default_mingw_compiler_flags="$default_mingw_pp_flags -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4"
C_FLAGS = -D_FORTIFY_SOURCE=2 -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -O3 -DNDEBUG   -Dmain=SDL_main
CXX_FLAGS = -mwindows -std=gnu++11 -D_FORTIFY_SOURCE=2 -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -Wno-error -Wall -Wextra -Wno-unknown-pragmas -Wno-fatal-errors -O3 -DNDEBUG -O3   -Dmain=SDL_main

As additional info, the native Linux cmake package does keep -DNDEBUG -O3 when the build is set to Release.

What do you think? Thanks!

xantares commented on 2019-11-10 12:10

the new mingw runtime 7.0.0 now supports FORTIFY_SOURCE, but you get undefined references to __chk functions from libssp now

you can see the discussion in mingw-w64-configure

Martchus commented on 2019-11-10 12:08

Why did you change _FORTIFY_SOURCE=0?

hhromic commented on 2019-10-16 22:51

Hi again, I think I figured it out now. The variable I need to use is CMAKE_STAGING_PREFIX, which is used for cross-compiling environment such as this package. I tested and does exactly what I needed.

Thanks anyway!

hhromic commented on 2019-10-16 21:30

Hi guys, First of all, thank you very much for putting together this wrapper package. Is simply amazing and makes things so easy to use!

However I'm having trouble setting CMAKE_INSTALL_PREFIX in my builds. When I set this variable, the CMAKE_SYSTEM_PREFIX_PATH ends up wrong and things like find_path() stop working. For example:

No install prefix provided, default is /usr/x86_64-w64-mingw32:

CMAKE_SYSTEM_PREFIX_PATH is /usr;/usr/x86_64-w64-mingw32;/

Install prefix provided -DCMAKE_INSTALL_PREFIX=/tmp/install:

CMAKE_SYSTEM_PREFIX_PATH is /usr;/tmp/install;/

As you can see, the system path /usr/x86_64-w64-mingw32 is not present anymore and of course find_path() doesn't find things correctly.

I noticed that in other environments such as MSYS2 or standard cmake, things work as expected. For example in standard cmake in ArchLinux:

No install prefix provided, default: /usr/local:


Install prefix provided -DCMAKE_INSTALL_PREFIX=/tmp/install:


As you can see, the system path /usr/local is actually duplicated, therefore if you change the default CMAKE_INSTALL_PREFIX it doesn't break.

Now, I noticed that in the mingw-w64-cmake package, the wrapper actually passes CMAKE_INSTALL_PREFIX=${mingw_prefix} and providing it externally actually overrides it. Therefore, explaining the issue.

With all that, I would kindly like to ask how I'm supposed to set a custom CMAKE_INSTALL_PREFIX of my own with this mingw-w64-cmake package?

Is this a short-coming of the wrapper? Thanks!

xantares commented on 2019-03-27 20:01

I just tested, and it fixes it.


xantares commented on 2019-03-27 09:46


I think it appears only in C++ and when using a cmake config file (FooConfig.cmake used by find_package(Foo))

the problem appears with jsoncpp for example:

$ aurman -S --noconfirm --noedit mingw-w64-jsoncpp

$ git clone --depth 1 && cd pkgtest && x86_64-w64-mingw32-cmake . && make

we can see that ./CMakeFiles/t_jsoncpp.dir/includes_CXX.rsp contains "-isystem /usr/x86_64-w64-mingw32/include"

interesting thing is that with cmake 3.13.4 the includes_CXX.rsp is not used/present

Martchus commented on 2019-03-26 20:05

I created an issue:

xantares commented on 2019-03-26 19:59

yeah, on simple stuff it goes fine here too.

I've got it with:

compiling t_agrum

Martchus commented on 2019-03-26 19:56

Do you have a simple example? I've just tried with a simple project file and couldn't reproduce it. That's currently preventing me from filing an issue.

By the way, if you're wondering why I haven't updated Qt to 5.12.2 yet - that issue delayed my tests.