mingw May 2020

mingw@lists.fedoraproject.org

7 participants
8 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

CMake fails to find Boost library since a recent update
by Jan Niklas Hasse 27 May '20

27 May '20

Hi! I've noticed that since a few days my CI builds using Fedora are failing to cross-compile to Windows because CMake can find Boost, but not the libraries (serialization and system in my case): CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 (message): Could NOT find Boost (missing: serialization system) (found suitable version "1.69.0", minimum required is "1.40") Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake/Modules/FindBoost.cmake:2162 (find_package_handle_standard_args) CMakeLists.txt:25 (find_package) This is the line in my CMakeLists.txt: find_package(Boost 1.40 COMPONENTS serialization system REQUIRED) This seems to be caused by the update of mingw64-boost from 1.66 to 1.69, because when I downgrade the package, the builds work again. Anyone else noticed this too and has an idea how to make CMake find the libraries again (without the downgrade workaround)?

1 0

Changes in F32
by Ron Yorston 27 May '20

27 May '20

I use the MinGW toolchain on Fedora to build busybox-w32, a WIN32 port of BusyBox[1][2]. I've recently updated to Fedora 32 and was disappointed to find that binaries built there are bigger than those built on Fedora 31. I presume this is due to the switch to dwarf-2 exceptions[3] as the versions of most things seem to be otherwise unchanged. Even the 64-bit build is affected. Most sections are the same size but for .text F31 gives: Idx Name Size VMA LMA File off Algn 0 .text 00070e58 0000000000401000 0000000000401000 00000400 2**4 and F32: 0 .text 00071678 0000000000401000 0000000000401000 00000400 2**4 So, 2080 bytes larger. The 32-bit build has a similar increase in .text (2288 bytes) and a whole new section (7604 bytes). There are minor differences in some other sections but I'm not too concerned about them. F31: Idx Name Size VMA LMA File off Algn 0 .text 00068754 00401000 00401000 00000400 2**4 F32: Idx Name Size VMA LMA File off Algn 0 .text 00069044 00401000 00401000 00000400 2**4 3 .eh_frame 00001db4 0047d000 0047d000 0007a000 2**2 Can anything be done to reduce this? I'm used to agonising about changes that add 16 bytes, an additional 10KB for no new functionality is quite a shock. For the moment I'll continue to build releases on F31. Ron [1] https://frippery.org/busybox [2] https://github.com/rmyorston/busybox-w32 [3] https://fedoraproject.org/wiki/Changes/Mingw32GccDwarf2

1 0

Adding %mingw_make_build and %mingw_make_install
by Sandro Mani 27 May '20

27 May '20

Hi I'm thinking of adding %mingw_make_build and %mingw_make_install as counterparts to %make_build and %make install, see [1]. Comments/objections? Sandro [1] https://src.fedoraproject.org/rpms/mingw-filesystem/pull-request/5

3 3

Package reviews
by Sandro Mani 22 May '20

22 May '20

Hi I've got quite a number of mingw packages I maintain in this COPR repo [1] which I wouldn't mind moving to the main repos, but so far I've shied away from submitting all the review requests not sure if there are people in the mingw group here having the capacity to perform the reviews. Is there anyone here who might also have a number of mingw packages to submit for review with whom I can swap reviews? Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-extras/builds/

2 2

Portaudio problem
by Richard Shaw 14 May '20

14 May '20

I've had this working before because I built FreeDV for windows 32 and 64 bit before, but even though the package builds "fine" the resultant DLL doesn't seem to work. dllexp in Windows shows no functions and the program I'm trying to run, fldigi, fails with an error message that libportaudio-2.dll is broken. Nothing in the build log is jumping out at me... Here's a link to the Review Request anyway, but I need to get this fixed before it's built in Fedora... https://bugzilla.redhat.com/show_bug.cgi?id=1835852 Thanks, Richard

2 1

Autotools install location for DLL problem
by Richard Shaw 13 May '20

13 May '20

Ok, so CMake knows that mingw shared libraries go in <mingw root>/bin and not <mingw root>/lib but autotools does not. What's the best way to fix this? I manually moving the files in the spec file but then the pkgconf file would need to get patched as well. There's got to be a more elegant way of fixing this than brute force... Is there? Thanks, Richard

2 2

Static or shared libraries?
by Richard Shaw 11 May '20

11 May '20

Is it documented anywhere that static or shared libraries are preferred? I've got several mingw packages in my COPR[1] that can and probably should be added to Fedora, but I'm also a developer on a project and I produce windows installers from my Fedora machine. Some of the dependencies I built with shared (dll) libraries and probably spent 10's of hours figuring out how to see which ones needed to be bunded in the installer https://github.com/drowe67/freedv-gui/blob/master/cmake/GetDependencies.cma… So that makes me thing that static libraries would be better or should be enforced. If not, how do you package programs with shared libraries? Thanks, Richard

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw May 2020