mingw_cflags vs optflags
by Sandro Mani
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/
3 years, 5 months
Vent time
by Michael Cronenworth
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
3 years, 5 months
HEADS UP: Upcoming toolchain update
by Sandro Mani
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
3 years, 5 months
Differences in 32bit and 64bit builds
by Richard Shaw
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
3 years, 5 months
widows.h
by Bob Tennent
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?
3 years, 6 months
