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: 2.273461
First Submitted: 2013-04-17 12:11
Last Updated: 2018-02-23 15:30

Required by (112)

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.

All comments