mingw

mingw@lists.fedoraproject.org

5908 discussions

Help with conversion to native build
by Richard Shaw 16 Jul '25

16 Jul '25

I'm working on a PR for libsamplerate to build native MinGW packages. Initially I stuck with the autotools build but for some reason '-z' was sneaking into the LDFLAGS and I couldn't figure out how to remove it. So then I decided to transition to a CMake build which is working including tests, the problem is even though I have the macros in the spec file per the guidelines, the debuginfo stuff seems to be missing. Can someone take a look? https://src.fedoraproject.org/fork/hobbes1069/rpms/libsamplerate/c/9199ef8a… Thanks, Richard

2 1

GCC 15 is not working for Wine-Mono
by Michael Cronenworth 31 May '25

31 May '25

Hello, I needed to upgrade wine-mono for Wine 10.5 released last week. The builds for F42 and prior succeed. The build for Rawhide fails. Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=131200142 Error seen in build.log: make[1]: Entering directory '/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/build/FNAMF-x86' i686-w64-mingw32-gcc -o debug.o -D_WIN32_WINNT=0x0602 -D__WINESRC__ --std=c99 -c -Wall -Wno-format -Werror -gcodeview -g -I/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/../.. -I/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/../../wine /builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/../../wine/debug.c make[1]: Leaving directory '/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/build/FNAMF-x86' /tmp/ccREFp1H.s: Assembler messages: /tmp/ccREFp1H.s:6104: Error: can't resolve .debug$T - Ltext0 /tmp/ccREFp1H.s:8549: Error: can't resolve .debug$T - Ltext0 make[1]: *** [/builddir/build/BUILD/wine-mono-10.0.0-build/wine-mono-10.0.0/FNA/lib/FNAMF/Makefile:15: debug.o] Error 1 Is this a known issue? Thanks, Michael

2 3

Re: Rebuilding tesseract dependents in F42 for soversion change
by Neal Gompa 02 Oct '24

02 Oct '24

On Wed, Sep 25, 2024 at 2:49 PM Michel Lind <michel(a)michel-slm.name> wrote: > > Dear all, > > This PR: https://src.fedoraproject.org/rpms/tesseract/pull-request/6 > was recently merged and built: https://bodhi.fedoraproject.org/updates/FEDORA-2024-41b92bf172 > > It backports a PR that's merged upstream to change the Tesseract > SOVERSION from maj.min.patch to only maj.min (Tesseract follows SemVer > and already uses maj.min for its Windows build, so the Linux versioning > was just a misconfiguration). So in the future, patch releases can be > built without having to rebuild dependents! > > This also splits off tesseract-libs into a separate subpackage, which > will make it easier in the future to have compat versions of tesseract > since the libraries could coexist. > > Unfortunately I omitted to mention that tesseract dependencies have to > be rebuilt - so we have to move slightly faster than usual to rebuild > the dependents. > > This will be done in f42-build-side-96586 that's already created for > updating ffmpeg (one of those packages that need tesseract). > I attempted a rebuild to deal with a bodhi error where it wouldn't let me land it with the NVR reserved by another obsolete update, but I'm getting bizarre failures for the mingw builds. Can someone help, please? Here's the failed build task: https://koji.fedoraproject.org/koji/taskinfo?taskID=124237852 It seems like something has gone wrong with trying to use the C++ standard library in MinGW somehow? -- 真実はいつも一つ！/ Always, there's only one truth!

3 3

Re: Rebuilding tesseract dependents in F42 for soversion change
by Neal Gompa 02 Oct '24

02 Oct '24

On Tue, Oct 1, 2024 at 4:55 AM Michael J Gruber <mjg(a)fedoraproject.org> wrote: > > Am Di., 1. Okt. 2024 um 00:07 Uhr schrieb Sandro Mani <manisandro(a)gmail.com>: > > > > > > On 30.09.24 23:35, Neal Gompa wrote: > > > On Wed, Sep 25, 2024 at 2:49 PM Michel Lind <michel(a)michel-slm.name> wrote: > > >> Dear all, > ... > > >> Unfortunately I omitted to mention that tesseract dependencies have to > > >> be rebuilt - so we have to move slightly faster than usual to rebuild > > >> the dependents. > > >> > > >> This will be done in f42-build-side-96586 that's already created for > > >> updating ffmpeg (one of those packages that need tesseract). > > >> > > > I attempted a rebuild to deal with a bodhi error where it wouldn't let > > > me land it with the NVR reserved by another obsolete update, but I'm > > > getting bizarre failures for the mingw builds. Can someone help, > > > please? > > > > > > Here's the failed build task: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=124237852 > > > > > > It seems like something has gone wrong with trying to use the C++ > > > standard library in MinGW somehow? > > > > This is most likely due to the fact that mingw-crt-12.0.0 for the > > mingw32 and mingw64 variants was initially built with the incorrect > > default msvcrt. This has since been fixed, but mingw-gcc also needs to > > be rebuilt. I'm taking care of this now. > > I'd like to reiterate my question about recursive dependencies: > > │ Are you planning to build recursive dependencies, or should we take > │ care of that? > │ > │ I maintain mupdf and had been holding back a version update so far. It > │ would make sense to build this into your side-tag before you or I > │ rebuild mupdf's dependencies there. > > zathura-pudf-mupdf, python-PyMuPDF and qpdfview are affected by a > mupdf update which changes soname. They *should not break* due to the > side-tag rebuild which keeps soname. So it's more about timing and the > preference to separate or combine updates (for rawhide; for release > I'd combine). > You should probably take care of it now in Rawhide, but there will be a side-tag opened for F41 to bring back this there (as well as ffmpeg7) that you may want to put that into so we can ship it all at once. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Getting fedora boost-mingw to include BoostConfig.cmake
by Albert Astals Cid 28 Aug '24

28 Aug '24

How hard would be for mingw64-boost/mingw32-boost to include BoostConfig.cmake? boost-devel does but it's on the wrong "sysroot". Cheers, Albert

2 7

MinGW AArch64/ARM64 target?
by Neal Gompa 11 Aug '24

11 Aug '24

Hey folks, With the advent of Windows on Arm (WoA) computers, I was wondering if we're going to start offering an aarch64/arm64 target with the MinGW toolchain. I think it probably makes sense to start offering support for this now as it seems like WoA isn't a complete failure this time around. In particular, it'd be nice to eventually be able to build Fedora Media Writer as a WoA app, and it would enable filling out Wine's WoA target too. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Packages that are due to be orphaned
by Michael Cronenworth 31 Jul '24

31 Jul '24

Hi, My time for package maintenance grows shorter by the day. I have to orphan/retire the following as they are FTBFS. * mingw-sane-backends - only builds a Fujitsu driver anyway. There are numerous issues with the latest GCC compiler. Mainly type conversions. * mingw-p11-kit - Numerious compiler warnings due to newer GCC usage. I'll give folks a week or two to take them before I retire them. Thanks, Michael

1 0

Fedora 38: mingw64-cmake fails when it used to succeed
by Albert Astals Cid 13 Sep '23

13 Sep '23

Since very recently (it worked 4 days ago), running mingw64-cmake -G Ninja .. fails with /usr/bin/mingw64-cmake: line 91: fg: no job control Any idea what can be causing it? Last time the problem was a missing dependency it seems? [1] But i have cmake installed so if it's a missing dependency it's not that one. Cheers, Albert [1] https://stackoverflow.com/questions/33124261/usr-bin-mingw32-cmake-line-84-…

3 3

Is it possible / viable to use lld linker with mingw?
by Marián Konček 30 Aug '23

30 Aug '23

The current mold / lld linkers can be significantly faster than bfd. If the developer does not need linker scripts or other BFD-specific functionality, they can use these linkers for the typical development process. It would be helpful to save a few milliseconds if lld was also usable with mingw. (Mold is not available for this purpose under an open-source license.) There is an upstream project https://github.com/mstorsjo/llvm-mingw which mentions some limitations. Is anyone able to tell if it is worth experimenting with it or possibly adding it to Fedora? -- Marián Konček

1 0

Quick review of libsodium
by Marián Konček 22 Aug '23

22 Aug '23

Hi, could someone please LGTM this change? https://src.fedoraproject.org/rpms/libsodium/pull-request/3 Thanks. -- Marián Konček

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw