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: 50
Popularity: 0.179528
First Submitted: 2013-04-17 12:11
Last Updated: 2020-11-07 21:45

Dependencies (5)

Required by (211)

Sources (2)

Latest Comments

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

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.

xantares commented on 2019-03-26 19:47

yes, this is bad I've got it too.

if you do file an issue can you post its link here too so I can follow ?

Martchus commented on 2019-03-26 19:40

I'm going to file an issue. I reproduce this by building one of my projects, e.g. Syncthing Tray. When I downgrade the CMake version installed in the systemd container and re-run CMake it works again. So it is quite likely that a change in CMake is responsible. Someone on the #cmake channel on free node also told me that there were changes regarding implicit include directories made.

xantares commented on 2019-03-26 19:33

how do i reproduce exactly ?

is there a bug report somewhere ?

Martchus commented on 2019-03-26 19:26

It appears CMake 3.14.0 was a bad release. One of the bug I've encountered so far concerns this package which sets CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES via command line parameter. That appears to be broken resulting in compile errors like:

/usr/i686-w64-mingw32/include/c++/8.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory                                                                                                                                        #include_next <stdlib.h>

So I recommend downgrading to CMake 3.13.4 for now.

Martchus commented on 2019-03-05 17:39

The -fstack-protector-strong flag causes further trouble:

So if we would like to re-enable it (using the patched GCC) we need to take care of the linker issue as well. Apparently it helps to add -lssp to the linker line. Maybe adding -fstack-protector-strong itself helps, too.