Package Details: mingw-w64-cmake 1-40

Git Clone URL: https://aur.archlinux.org/mingw-w64-cmake.git (read-only, click to copy)
Package Base: mingw-w64-cmake
Description: CMake wrapper for MinGW (mingw-w64)
Upstream URL: http://fedoraproject.org/wiki/MinGW
Licenses: GPL
Submitter: brcha
Maintainer: xantares
Last Packager: xantares
Votes: 57
Popularity: 0.44
First Submitted: 2013-04-17 12:11 (UTC)
Last Updated: 2022-12-05 17:39 (UTC)

Latest Comments

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

xantares commented on 2018-02-07 17:29 (UTC)

ok, seems good

jpcima commented on 2018-02-07 01:26 (UTC)

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?

set (CMAKE_SYSTEM_PROCESSOR i686) and set (CMAKE_SYSTEM_PROCESSOR x86_64)

xantares commented on 2017-08-17 15:36 (UTC) (edited on 2017-08-17 15:38 (UTC) by xantares)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-09-11 16:53 (UTC) by Martchus)

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 (UTC)

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 (UTC)

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 (UTC)

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) -DCMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES:PATH=${mingw_prefix}/include \ -DCMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES:PATH=${mingw_prefix}/include \

markand commented on 2016-09-02 05:11 (UTC) (edited on 2016-09-02 10:44 (UTC) by markand)

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) project(test) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED On) 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 . make 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.

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