Package Details: mingw-w64-cmake 1-39

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: 54
Popularity: 0.173715
First Submitted: 2013-04-17 12:11 (UTC)
Last Updated: 2021-12-03 20:35 (UTC)

Latest Comments

class101 commented on 2022-01-01 02:30 (UTC) (edited on 2022-01-01 02:33 (UTC) by class101)

I see that's a different usage.

In my opinion your wrapper script works great. All it needed I explained in the bottom on my previous comment, if you convert the parameters into environnement variable, the expected result will probably be what you want, and it executes what I ask him to without problems.

In my opinion it is a common practice to replace a binary by a wrapper script on Linux to inject an environnement variable, but never seen a script to inject parameters in a program

Currently I'm using a lot CLion between windows and linux, with around 6 different toolchains and each with its debug and release build directory automatically managed by clion.

Near that I have to take care one of my co worker is under visual studio

So if I can avoid hacks into what CLion does, I prefer :D

It is just like you in the IDE, I set this once at the IDE setting level and then it works for all projects

hhromic commented on 2021-10-31 18:09 (UTC)

Thanks @Martchus, that's indeed a very good point. We use this on a CI setup where the sources are not expected to change after configuring the build, but yes if you expect the cmake files to change at some point, then you need to make sure you are sourcing the environment like the wrapper does :+1:

Martchus commented on 2021-10-31 17:26 (UTC) (edited on 2021-10-31 17:27 (UTC) by Martchus)

When following @hhromic's example, just take care to source the mingw-w64 env because otherwise linker flags will be missing. (The wrapper sources it but of course that has no effect on the subsequent plain cmake calls which may invoke a reconfiguration of your project when CMake files change.)

hhromic commented on 2021-10-31 16:59 (UTC)

In addition to what Martchus said, you also don't need to use the wrapper for every cmake command, just the initial invocation to configure the build. After the build is configured, you can use the real cmake binary to run further cmake commands. For example:

$ x86_64-w64-mingw32-cmake -B build -DCMAKE_BUILD_TYPE=Release ...
$ cmake --build build
$ cmake --install build

This will pick up the environment set by the wrapper to configure the build itself. This works for me very well, but maybe other cmake experts could confirm this is a suitable approach too.

Martchus commented on 2021-10-31 15:12 (UTC) (edited on 2021-10-31 15:14 (UTC) by Martchus)

Just use the normal cmake command, e.g. when using Qt Creator I prefer doing all settings within the IDEs config and don't use this wrapper at all. You can still use the wrapper for initial configuration of course.

class101 commented on 2021-10-31 12:49 (UTC) (edited on 2021-10-31 13:25 (UTC) by class101)

mingw-w64-cmake breaks --build and other commands

Hello, I wanted to bring attention that this package breaks the use of the --build command.


After installating mingw-w64-cmake and attempting to use the --build, as the following command used by CLion fails

/usr/bin/x86_64-w64-mingw32-cmake --build /home/${USER}/dev/.../cmake-build-debug-mingw --target target -- -j 6
CMake Error: Unknown argument -j
CMake Error: Run 'cmake --help' for all supported options.


/usr/bin/x86_64-w64-mingw32-cmake --build /home/{USER}/dev/.../cmake-build-debug-mingw
CMake Error: Unknown argument --build
CMake Error: Run 'cmake --help' for all supported options.

Root cause

It is specified in the cmake --help-full documentation that the build options should be passed as : [-- <build-tool-options>]

 Generate a Project Buildsystem
  cmake [<options>] <path-to-source>
  cmake [<options>] <path-to-existing-build>
  cmake [<options>] -S <path-to-source> -B <path-to-build>

 Build a Project
  cmake --build <dir> [<options>] [-- <build-tool-options>]

But as mingw-w64-cmake rewrite the cmake launcher, it is forcing options to be added before the --build parameter, and so on, breaks its use.


One solution would be to change

PATH=${mingw_prefix}/bin:$PATH cmake \
    -DCMAKE_INSTALL_PREFIX:PATH=${mingw_prefix} \
    -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake \
    -DCMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/x86_64-w64-mingw32-wine \


PATH=${mingw_prefix}/bin:$PATH cmake "$@" -- \
    -DCMAKE_INSTALL_PREFIX:PATH=${mingw_prefix} \
    -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake \

I have checked, this works with --build now, but fails with others -_-.

So I believe to really fix this package, you will need to bring a more elegant wrapper script, or rebuild from sources to work properly with all the possible cmake use cases.

So it seem cmake is waiting for the [options] tag at different positions depending on the requested command line, this sound very difficult to make a perfect 'all-in-one' wrapper script to support everything

Maybe a cleaner way would be to pass them as environment variable, I have read in the docs that CMake is supposed to fork them

Tested on cmake 3.21.4

Edit: This seems to work better

PATH=${mingw_prefix}/bin:${PATH} \
CMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake \
CMAKE_INSTALL_PREFIX=${mingw_prefix} \
CMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/x86_64-w64-mingw32-wine \
cmake "$@"

Martchus commented on 2021-08-11 12:54 (UTC)

@nik123true When using static libraries there are some rough edges. Maybe this CMake find module needs indeed fixing to work with our packaging. (For using the mingw-64-qt6-*-static packages I've created as some of Qt's dependencies are problematic and I needed a way to globally prefer static libs over dynamic libs. It is a very hacky approach but as a last resort you can try something similar.)

nik123true commented on 2021-08-11 11:46 (UTC)

The static version of the library (GLEW::glew_s) is not detected by FindGLEW() in CMake. This does not seem to be the case when building in Windows using MSYS2. I can't seem to track down what is causing the issue exactly. Sorry about that.

jpcima commented on 2021-05-25 01:29 (UTC) (edited on 2021-05-25 01:38 (UTC) by jpcima)

The source statement in the script does not work when /bin/sh is linked to dash. This should changed to . instead.

Edit: . is not sufficient, it is unable pass the argument to mingw-env. changing to #!/bin/bash is not a bad solution either.

Martchus commented on 2021-02-04 16:17 (UTC)

That's true. I've also realized that we'd still miss dynamically sourcing the environment variables provided by mingw-w64-environment (which supposedly instead needed to be hard-coded into the presets at build-time of this package).

xantares commented on 2021-02-04 16:09 (UTC)

It seems it would better suit per-projects configurations, not our distribution-wide settings.

Martchus commented on 2021-02-04 14:15 (UTC)

This recently added CMake-feature might be useful:

(I don't have any concrete plan to use it here. I'm just mentioning it because some people here might find it interesting.)

Martchus commented on 2021-01-31 17:55 (UTC)

When using Qt Creator I don't use any of those wrappers except maybe for initially preparing the build directory manually beforehand. Otherwise it seems easier to create a kit within the settings which has an appropriate CMake configuration (but still let it use CMake directly). It is now also possible to set initial CMake parameters directly within the build configuration.

pingplug commented on 2021-01-31 17:40 (UTC)

qt creator use cmake -E capabilities to check cmake version and file-api, -Dxxx before -E cause an error.

xantares commented on 2021-01-07 17:30 (UTC)

your patch is ok, but its probably useless to have it

jpcima commented on 2020-12-08 00:47 (UTC)

@xantares not anything that I would call a use-case, more an expectation. This lead to error in one occasion, in attempt to use it in CI setting.

is there an inconvenient to the solution proposed?

xantares commented on 2020-12-07 17:26 (UTC)

@jpcima what is your use-case ?

Martchus commented on 2020-12-07 14:23 (UTC) (edited on 2020-12-07 14:36 (UTC) by Martchus)

I'd just call the regular CMake instead, at least for --build and --install that works just fine:

jpcima commented on 2020-12-07 13:09 (UTC)

Some commands are non-working under the wrapper: -E, --build, and some others. Please consider this version of script:

bburlacu commented on 2020-11-24 15:32 (UTC)

yes, I just built it myself without wine.

xantares commented on 2020-11-24 15:08 (UTC)

are you sure gmp builds without wine ?

bburlacu commented on 2020-11-24 15:04 (UTC)

you are right, didn't look that far into the dependencies. problem fixed by removing wine from the gmp PKGBUILD.

xantares commented on 2020-11-24 14:55 (UTC)

it probably installs wine when building gmp which is a dependency of ceres

bburlacu commented on 2020-11-24 14:39 (UTC)

IMHO having Wine as an optional depend is totally not worth it. yay or other package managers will still try to install it when resolving dependencies, I'm having a load of trouble trying to install mingw-w64-ceres-solver and there is no way to avoid wine, which eventually fails because it can't resolve all its dependencies.

Martchus commented on 2020-11-08 15:13 (UTC) (edited on 2020-11-08 15:54 (UTC) by Martchus)

As mentioned in your PR, I patched Qt 6 and the Vulkan library problem was just due to forcing static libraries. So I suppose all that's left is actually specific to the static version. I'll create a separate package (mingw-w64-cmake-static) for that.

xantares commented on 2020-11-07 12:21 (UTC)

I dont know where to start, what are the specific issues you're talking about ?

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:

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:


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:

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_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

Martchus commented on 2019-11-10 12:08 (UTC)

Why did you change _FORTIFY_SOURCE=0?

hhromic commented on 2019-10-16 22:51 (UTC)

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!

hhromic commented on 2019-10-16 21:30 (UTC)

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:


Install prefix provided -DCMAKE_INSTALL_PREFIX=/tmp/install:


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 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!

xantares commented on 2019-03-27 20:01 (UTC)

I just tested, and it fixes it.


xantares commented on 2019-03-27 09:46 (UTC) (edited on 2019-03-27 10:32 (UTC) by xantares)


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

I created an issue:

xantares commented on 2019-03-26 19:59 (UTC)

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

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

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

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

how do i reproduce exactly ?

is there a bug report somewhere ?

Martchus commented on 2019-03-26 19:26 (UTC)

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

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.

xantares commented on 2019-01-05 09:57 (UTC) (edited on 2019-01-05 10:12 (UTC) by xantares)

Martchus, I found this report regarding -fstack-protector-strong:

Does the example crash on native windows (It does not on wine) ? Maybe I can try to backport the proposed patch.

xantares commented on 2019-01-05 08:48 (UTC)

Good to know, although I dont know why it would crash.

I think I've got similar issues for qt applications when not stripping the .exe

I'm including your changes.

Thanks for investigating the flags and stuff.

Martchus commented on 2019-01-05 01:06 (UTC) (edited on 2019-01-05 01:10 (UTC) by Martchus)

Seems I've got already punished for playing too much with the compile flags :-)

In particular -fstack-protector-strong causes the application to crash even before main() is invoked. So if you decide to follow my suggestions, don't include that flag.

But I still find it weird. When running the app compiled with that flag within WINE it does not crash. The crash is only observable under Windows. Hence I only discovered the issue quite late. The crash also does not happen with a plain application which links only against libstdc++ but not Qt or other libraries and prints "Hello world!" via std::cout.

Just out of curiosity, has anybody an explanation for this?

Martchus commented on 2018-12-22 13:57 (UTC) (edited on 2019-01-05 01:08 (UTC) by Martchus)

Can you change the default flags of this package and mingw-w64-configure to match the default flags more closely?

I would certainly remove -g for the following reasons:

  • Consistency with regular flags.
  • It serves no purpose as debugging information gets stripped out unconditionally anyways.
  • Enabling debugging information leads to bigger object files and DLLs during the build. This is annoying if you want to keep build artifacts for a while around. One use case for this is speeding up rebuilds using ccache. With -g one has to choose a ridiculously big cache size to make this actually work. Another use case is keeping the actual build directory, e.g. to be able to use --repackage in case something was wrongly packaged.
  • I'm aware that using -g and -O2 at the same time is not necessarily bad. Sometimes one wants to debug optimized binaries. However, that's not the case here. At least not for me and likely not for the default user.

It would be great if the script would read the flags from a certain environment variables, e.g. MINGW_CFLAGS and MINGW_CPPFLAGS and MINGW_CXXFLAGS and only impose the defaults. Then people with extra wishes (e.g. adding -g) could do that by adjusting their makepkg.conf or specifying the variable on the makepkg invocation if it should only affect a certain package. That is how it already works for regular packages. Why limiting ourselves when building mingw-w64 packages?

I'm also aware the script currently allows to extend the flags ($mingw_c_flags $CFLAGS). However, that only works for overriding flags which have a negating counterpart. And further, this only works on package level. A user who wants specific flags would need to adjust each and every PKGBUILD to export that variable.

Of course I would also adjust mingw-w64-qt5-base and add a line similar to the regular package:
The packaging guild lines would need to be adjusted, too.

I did a few tests and it seems most of the regular defaults also work for mingw-w64. So what about the following defaults:

MINGW_CPPFLAGS="-D_FORTIFY_SOURCE=2" # that one we had previously as CFLAGS/CXXFLAGS
MINGW_CFLAGS="-O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4" # almost everything from regular packages seems applicable + -fexceptions --param=ssp-buffer-size=4
MINGW_CXXFLAGS="-O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4" # almost everything from regular packages seems applicable + -fexceptions --param=ssp-buffer-size=4
MINGW_LDFLAGS="-Wl,-O1,--sort-common,--as-needed" # the -z options are ELF specific and therefore not applicable

See my comment from 2019-01-05 why -fstack-protector-strong is not applicable.

I would keep -fexceptions --param=ssp-buffer-size=4 because we had these so far and I don't want to break anything. Maybe some peculiarities of Windows/PE require them. Especially turning on exceptions for C code might have a reason specific to the SJLJ and SEH exception handling on Windows so better keep it.

I did not include -march=x86_64/i686 and -mtune=generic because -march=x86_64/pentiumpro and -mtune=generic are present anyways. This is observable by invoking the compiler with -Q -v. Leaving that flags out avoids handling i686 and x86_64 differently. (The architectures pentiumpro and i686 should be the same.)

drakkan commented on 2018-05-11 15:12 (UTC)

thanks! actually meson does not allow to have wine as optdepend

xantares commented on 2018-05-11 11:22 (UTC)

Ok, split into mingw-w64-wine. It's a good idea to mark it as optdepend as wine is a big dependency, I only add it to package that explicitely need runtime support. xan.

drakkan commented on 2018-05-10 21:27 (UTC)

${_arch}-wine should be a separate package, I would like to add it as depends for mingw-w64-meson and so replace wine here

without the need to have this package as depends, thanks!

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?


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.

xantares commented on 2016-07-13 20:05 (UTC)

You can override the -02 flag by appending -O0, ie "-O2 -O0" are valid CFLAGS, the last (-O0) value overrides the level 2 optimization O2.

Martchus commented on 2016-07-13 19:59 (UTC)

Of course I know that debug symbols are stripped anyways. I was just wondering about the combination with -O2 but your explanation makes sense. I just mentioned -g because I've read the previous discussion. Actually I want to get rid of -O2 as a workaround for the mentioned issue (see my first comment). Hence overwriting (and not just appending) would still be useful for me. Maybe there are other use cases, too. If you like, you can try to reproduce the issue (should only take 1 minute).

xantares commented on 2016-07-13 19:40 (UTC)

"-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 so if you wanted to override flags just to disable -g it's useless. xan.

Martchus commented on 2016-07-13 18:32 (UTC) (edited on 2016-07-13 19:09 (UTC) by Martchus)

Thanks for your fast response :-) I know appending is possible in mingw-w64-configure. If you look at the code in my repo you'll see I also added this for mingw-w64-cmake. However, it would be nice to get completely rid of some flags. That is why I'd like to introduce another environment variable for that. I think this wouldn't hurt anyone. BTW: I also read the previous discussion about the default flags and I have to say that these are a bit strange indeed. In particular the combination of -g (which generated debugger information) and -O2 (which enables most of the available optimizations) doesn't make very much sense to me. EDIT: kalev from #fedora-mingw just told me that the reason they chose those particular build flags is to match the build flags regular Fedora binaries use as similar as possible.

xantares commented on 2016-07-13 18:16 (UTC) (edited on 2016-07-13 18:19 (UTC) by xantares)

hey, good idea, you can already do that in mingw-w64-configure by calling CFLAGS="-foo" ${_arch}-configure for flags to be appended to the default flags. I'll do the same here so you could do CFLAGS="-O0" ${_arch}-cmake xan.

Martchus commented on 2016-07-13 18:01 (UTC)

The default build flags should be configurable. I would propose to make the default build flags configurable via the environment variable CUSTOM_MINGW_FLAGS. Achieving this would be very simple: mingw_flags="${CUSTOM_MINGW_FLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4}" For consistency the changes should also be included in mingw-w64-configure. For the full source code of the proposed changes for both packages check out my PKGBUILDs repository: The reason I want to customize the build flags is that I the default ones are currently causing some trouble for me. In particular the compiler flag -O2 is causing page faults in the resulting application when an instance of std::stringstream is created in a shared library. As a workaround I need to use -O0 when building the shared library. If you want to reproduce the issue, here is a small example application and library: The commands to compile and run are also provided. I haven't had the time yet for further investigations of the issue, eg. to check whether other classes and the i686 architecture are also affected. Hence I haven't filed a bug report yet.

xantares commented on 2016-04-03 07:36 (UTC)

@chenxiaolong, thanks!

chenxiaolong commented on 2016-04-03 00:45 (UTC)

@xantares: As an alternative to copying DLLs in, you could simply set the WINEPATH environment variable to the bin directory. For example, I run my CMake tests with: WINEPATH="/usr/i686-w64-mingw32/bin;$(pwd)/libmblog" ctest -VV Something similar should also work in your script.

Cloudef commented on 2015-12-10 00:16 (UTC)

@xantares - You make good point of the native cflags. I did not consider those. It's weird fedora uses those weird flags as well (such as forcing exceptions, defining ssp parameter without enabling it, and just blatantly forcing -O2, -g, -Wall and -pipe, which are all situational options) - Yeah I sort of assumed this. I'm not sure what implications with moving the variables to the toolchain file would be though. In theory it should work the same, just without the warnings. Anyhow, thanks for your explanations.

xantares commented on 2015-12-08 13:10 (UTC)

xantares commented on 2015-12-08 13:07 (UTC)

@cloudef - Native flags from makepkg should not be read, the option !buildflags should be set in every mingw package, as you may have something like march=... which is invalid for cross-compiling I'm no expert in what those flags are and what they should be, I wanted to standardize the way mingw packages are built (see also mingw-w64-configure). I just took them from Fedora, and maybe they even changed. - I may have put them here because I had several packages relying on this behavior. I also use the toolchain files for development, and setting these variables in the toolchain would maybe be more annoying than the cmake unused warning. xan.

Cloudef commented on 2015-12-07 13:50 (UTC)

@xantares I usually expect packages on arch / aur to be close to upstream / vanilla as possible so the CFLAGS and BUILD_SHARED_LIBS came as bit of surprise. For example the CFLAGS looks quite similar to that of /etc/makepkg.conf default ones, but cmake _does_ read CFLAGS and CXXFLAGS first time cmake is ran, so it will actually work with /etc/makepkg.conf and you don't have to set them in the script, to avoid surprises for some. The fexceptions also makes no sense in the flags. nor the ssp buffer size without enabling ssp. -Wp, (while correct) is unneccessary. Also they set some defaults like -O2 with -g, this is all quite undesirable for people who simply assume it just handles cross-compilation using mingw but doesn't touch anything else. For BUILD_SHARED_LIBS, while I agree there are many horrible cmake projects and they do weird things regarding this global variable, or weird things in general. I think these hacks should be handled at their respective PKGBUILDs. CMAKE_INSTALL_LIBDIR INCLUDE_INSTALL_DIR LIB_INSTALL_DIR SHARE_INSTALL_DIR SYSCONF_INSTALL_DIR These variables also aren't standard CMake variables, apart from CMAKE_INSTALL_LIBDIR, that is actually provided by GNUInstallDirs cmake module. Others are hacks by project developers who dint bother reading CMake documentation and find about GNUInstallDirs, or the project was done with very early before GNUInstallDirs was available. While it's bit dirty, I don't propose removal of those variables. But you might be able to put them into toolchain file instead and avoid CMake warning about unused manually specified variables. I think this package is highly useful and really nice, but these 2 certainly were surprising to me. Especially since I actually used this in development instead of building AUR packages.

xantares commented on 2015-12-07 12:38 (UTC)

@cloudef: - these are CFLAGS that go well for mingw, I dont know the meaning of all flags, but you need at least to override native flags that would be invalid here - BUILD_SHARED_LIBS is set to build shared libs by default, but not every packages honor this canonical way of deciding static/shared, some use another name or set the default value to OFF

Cloudef commented on 2015-12-07 09:46 (UTC)

Why do you specify CFLAGS and force BUILD_SHARED_LIBS in the wrapper?

Schala commented on 2013-05-08 21:49 (UTC)

Oooh I didn't see that.

brcha commented on 2013-04-17 15:28 (UTC)

Why? What's the difference? The names are symlinked. I can make the scripts be *-w64-mingw32-cmake and symlinks mingw{32,64}-cmake, but I see no difference between the two combinations.

Schala commented on 2013-04-17 15:25 (UTC)

Could you rename the wrapper scripts to (i686/x86_64)-w64-mingw32? It helps. Thanks