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.68
First Submitted: 2013-04-17 12:11 (UTC)
Last Updated: 2022-12-05 17:39 (UTC)

Required by (278)

Sources (2)

Latest Comments

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

Martchus commented on 2020-11-07 11:05 (UTC)

In order to workaround certain issues regarding Qt 6 I've been extending the toolchain file. See this commit for further details and the actual change: https://github.com/Martchus/PKGBUILDs/commit/1c6dcbd4ed4482cdb8ed24276b5d3979bcd7dcdc

However, I still need to further test the static version and there are likely further adjustments required. So this is just a heads up. If I'm done it would be great do sync this package with my version on GitHub/PKGBUILDs.

And yes, this is hacky. Maybe some of this can be improved in the future, e.g. CMakes Vulkan find module might be fixed upstream to cover our needs.

hhromic commented on 2019-12-03 16:57 (UTC)

@Martchus that sounds good to me if -O3 is not problematic :)

Our builds seems to be working fine with it so no problem from my side. Yes the binaries are larger but I guess that is the cost to pay for the optimisation. If necessary one can always override with -O2 in the CMake project itself anyway.

So if you are okay, I'm happy to report my original problem as resolved. Thanks to both for the quick help, really appreciated.

Martchus commented on 2019-12-03 14:56 (UTC) (edited on 2019-12-03 14:57 (UTC) by Martchus)

However I noticed that CMake also defaults to [...]

This is actually a change I've expected and think it is ok and even wanted for consistency with how it works when invoking CMake manually.

So your observation regarding the flags is actually not different from how regular packages work: When CMAKE_BUILD_TYPE is empty (like it is by default) only the default flags from /etc/makepkg.conf (regular packages) or mingw-w64-environment (now for mingw-w64 packages) are used. If a specific package passes -DCMAKE_BUILD_TYPE=Release, additional build flags like -O3 are appended by CMake in addition to the default flags. Note that the official regular packages usually just don't pass -DCMAKE_BUILD_TYPE=Release to stick to the default.

I don't think -O3 is problematic (not for regular packages and not for mingw-w64 packages). So I usually have -DCMAKE_BUILD_TYPE=Release in my own (regular) packages. The only disadvantage I've noticed so far is an increased binary size (likely due to more aggressive inlining).

hhromic commented on 2019-12-03 11:56 (UTC)

@xantares thanks for working on this, appreciated.

I tested again now and it works! Release builds do have the -DNDEBUG define from the default CMake flags. The builds also work fine.

However I noticed that CMake also defaults to adding -O3 optimisation to Release builds and the mingw-w64 flags (now in mingw-w64-environment) seem to be wanting to use -O2 optimisation. This results in the following compiler flags for the build:

C_FLAGS = -D_FORTIFY_SOURCE=2 -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -O3 -DNDEBUG

The manpage of gcc states that when you use multiple -O flags the last takes precedence, meaning that the build ends up using -O3. If -O3 is known to be problematic for mingw-w64 builds then this might become a problem.

Maybe this was the original reason why you were previously forcing the C/CXX flags? Defaulting to -O3 seems to be a bit of a controversial topic in CMake help forums and Stack Overflow but is has been the default for years, even pre-CMake 3.0). Perhaps -O3 is not much of an issue nowadays? I'm not an expert in this field so can't state strong conclusions.

If -O2 is strictly required for mingw-w64 builds then we need to work out a way to remove the default -O3 from the CMAKE_${lang}_FLAGS_RELEASE_INIT variables set by the CMake's GNU compiler module in a clean manner.

A potential solution that I think would be good is to find a way to append (in contrast to prepend) the flags from mingw-w64-environment so they get inserted after the defaults from CMake and thus -O2 will take precedence.

I think this could be done cleanly in the mingw toolchain file. In this case we should make sure to not export the *_FLAGS variables (that get prepended) but instead code them in the toolchain file.

What do you think?

xantares commented on 2019-12-03 09:19 (UTC) (edited on 2019-12-03 09:19 (UTC) by xantares)

@hhromic can you test the new version ? I removed CMAKE_BUILD_TYPE and CMAKE_*_FLAGS_RELEASE, plus the flags are now taken from an env package

hhromic commented on 2019-12-02 09:07 (UTC) (edited on 2019-12-02 11:40 (UTC) by hhromic)

Fwiw, I've been testing the wrapper with removed -DCMAKE_BUILD_TYPE=Release and all -DCMAKE_*_FLAGS_RELEASE flags in the project I'm working on and all seems to be behaving as expected.

I fully agree that if there is any package requiring those, it should be fixed in said package and not in this generic wrapper. The wrapper should be as thin as possible for maximum compatibility, i.e. only set required paths and the toolchain.

Let me know if you would like me to do specific tests. Happy to help.

Martchus commented on 2019-12-01 21:04 (UTC)

No and unfortunately you left no information in the commit messages why you're enforcing the build type release and made it override the build type's flags:

The regular packages don't enforce a build type and rely on CMake picking up the CFLAGS/CXXFLAGS/LDFLAGS env variables. We could revert the script to do the same and see what happens. If only a few packages are affected it might make more sense to fix these than overriding all the flags in the generic wrapper.

xantares commented on 2019-12-01 20:16 (UTC)

@martchus do you recall why we set CMAKE_CXX_FLAGS_RELEASE and such ?

it seems CXXFLAGS/LDFLAGS are enough, as the flags appear twice

hhromic commented on 2019-12-01 11:42 (UTC) (edited on 2019-12-02 10:54 (UTC) by hhromic)

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:

    -DCMAKE_C_FLAGS_RELEASE="$CFLAGS" \
    -DCMAKE_CXX_FLAGS_RELEASE="$CXXFLAGS" \
    -DCMAKE_SHARED_LINKER_FLAGS_RELEASE="$LDFLAGS" \
    -DCMAKE_EXE_LINKER_FLAGS_RELEASE="$LDFLAGS" \

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: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake#L58

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_pp_flags="-D_FORTIFY_SOURCE=2"
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 (UTC)

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

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