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, 11 months
CMake fails to find Boost library since a recent update
by Jan Niklas Hasse
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)?
4 years
Changes in F32
by Ron Yorston
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
4 years
Package reviews
by Sandro Mani
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/
4 years
Portaudio problem
by Richard Shaw
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
4 years, 1 month
Autotools install location for DLL problem
by Richard Shaw
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
4 years, 1 month
Static or shared libraries?
by Richard Shaw
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.c...
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
4 years, 1 month
