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.72
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 »

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:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832

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: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/qt5-base#n34
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

https://github.com/mesonbuild/meson/issues/3562

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

https://aur.archlinux.org/cgit/aur.git/tree/toolchain-mingw.meson?h=mingw-w64-meson#n10

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

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