mingw June 2020

mingw@lists.fedoraproject.org

7 participants
5 discussions

mingw_cflags vs optflags
by Sandro Mani 02 Jul '20

02 Jul '20

Hi While looking through the mingw rpm macros, I noticed that we currently have mingw{32,64}_cflags = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 whereas for native packages we have optflags = -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection As I read the gcc docs and [1] (by no means an expert in the matter), I'd say the following might also make sense for the mingw cflags: - -Werror=format-security - -Wp,-D_GLIBCXX_ASSERTIONS - -fstack-protector-strong - -fasynchronous-unwind-tables - -fstack-clash-protection I've got a mass tool chain update scheduled before the F33 mass rebuild, I could in the same go also update the flags. Opinions? Sandro [1] https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/

2 2

Vent time
by Michael Cronenworth 24 Jun '20

24 Jun '20

Every time the Wine group issues a new Mono or Gecko update I know I'm in for hours, days, or weeks of trouble. Any one of the following items is guaranteed to happen. - Code that won't compile due to our newer tool set - Code that won't compile due to our older tool set - Major Makefile tooling changes on even minor updates (they have nothing else to do, apparently) New this week: A LLVM-based MinGW tool chain is shipped in the Wine Mono tarball and is required to build with their new CFLAGS. I didn't even know this chain existed. It looks maintained by one guy and I don't know why people spend their time reinventing the wheel like this. I'm about to give up packaging Wine. Thanks for the vent, Michael

1 0

HEADS UP: Upcoming toolchain update
by Sandro Mani 19 Jun '20

19 Jun '20

Hi I'm starting to work on upgrading the mingw toolchain according to [1], I'll be submitting the builds to the f33-build-side-24671 side tag and then merge when all is done. I'll be updating: mingw-binutils to version 2.34 mingw-headers to version 7.0.0 mingw-crt to version 7.0.0 mingw-winpthreads to version 7.0.0 mingw-w64-tools to version 7.0.0 mingw-gcc to version 10.1.1 mingw-gdb to version 9.2 Sandro [1] https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate

1 0

Differences in 32bit and 64bit builds
by Richard Shaw 15 Jun '20

15 Jun '20

I'm working on the ability to produce Windows builds of fldigi using the Fedora MinGW stack. Currently the 32bit builds compile with little to no warnings and appear to function properly, however, on 64bit builds there is a ton more warnings (I have to use -fpermissive) and the program segfaults shortly after launching. I have tried to capture a gdb stack trace but it produces no results... zero. For instance: dialogs/fl_digi.cxx: In function 'void cb_mnuVisitURL(Fl_Widget*, void*)': dialogs/fl_digi.cxx:2616:68: error: cast from 'HINSTANCE' {aka 'HINSTANCE__*'} to 'int' loses precision [-fpermissive] 2616 | if ((int)ShellExecute(NULL, "open", url, NULL, NULL, SW_SHOWNORMAL) <= 32) | ^ I see no such issues building for Fedora x86_64. I now the MinGW gcc is a port, but it's still based on GCC so I guess I don't understand why all the differences? Thanks, Richard

4 6

widows.h
by Bob Tennent 04 Jun '20

04 Jun '20

I've used mingw*-configure and mingw*-make successfully before but the package I'm working on has #include <windows.h> and #include <winbase.h>, What can I do?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw June 2020