Arch Linux User Repository

@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?

@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

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.

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:

• https://aur.archlinux.org/cgit/aur.git/commit/?h=mingw-w64-cmake&id=1e9e4690c2ed
• https://aur.archlinux.org/cgit/aur.git/commit/?h=mingw-w64-cmake&id=3174bb8705e8

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.

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

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

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!

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

Why did you change _FORTIFY_SOURCE=0?

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!

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:

CMAKE_SYSTEM_PREFIX_PATH is
    /usr/local;/usr;/;/usr;/usr/local;/usr/X11R6;/usr/pkg;/opt
                           ^^^^^^^^^^

Install prefix provided -DCMAKE_INSTALL_PREFIX=/tmp/install:

CMAKE_SYSTEM_PREFIX_PATH is
    /usr/local;/usr;/;/usr;/tmp/install;/usr/X11R6;/usr/pkg;/opt
                           ^^^^^^^^^^^^

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 mingw-cmake.sh 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!