mingw March 2021

mingw@lists.fedoraproject.org

5 participants
5 discussions

Getting useful gdb output
by Richard Shaw 24 Mar '21

24 Mar '21

I'm working on building a Win 64 bit version of a package I maintain to help upstream. Currently only 32-bit windows installers are produced because the 64-bit ones segfault on start up. Trying to get a useful debug environment on Windows has been a chore, but I have MinGW w64 installed including gdb, however, I can't see anything useful in the output. What else do I need to do to get useful output for troubleshooting Win64 specific MinGW issues? C:\Program Files (x86)\Fldigi-4.1.18>gdb fldigi.exe GNU gdb (GDB) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-w64-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from fldigi.exe...done. (gdb) run Starting program: C:\Program Files (x86)\Fldigi-4.1.18\fldigi.exe [New Thread 12596.0xdac] [New Thread 12596.0xbc4] [New Thread 12596.0x4048] [New Thread 12596.0x28dc] warning: Invalid parameter passed to C runtime function. [New Thread 12596.0x26dc] [New Thread 12596.0x1ba8] warning: onecore\com\combase\objact\objact.cxx(836)\combase.dll!00007FFDBC250827: (caller: 00007FFDBC24F6AC) ReturnHr(1) tid(dac) 800401F0 CoInitialize has not been called. warning: onecore\com\combase\objact\objact.cxx(836)\combase.dll!00007FFDBC250827: (caller: 00007FFDBC24F6AC) ReturnHr(2) tid(dac) 800401F0 CoInitialize has not been called. [New Thread 12596.0x2570] [New Thread 12596.0x2980] [New Thread 12596.0x2478] [Thread 12596.0x2980 exited with code 0] [New Thread 12596.0x360c] [Thread 12596.0x360c exited with code 0] [New Thread 12596.0x1aec] [New Thread 12596.0x38a0] [New Thread 12596.0x4c8] [New Thread 12596.0x3bc4] [New Thread 12596.0x3db0] [New Thread 12596.0x3c54] [New Thread 12596.0x3f28] [New Thread 12596.0x1e98] [New Thread 12596.0xa90] [New Thread 12596.0x3838] [New Thread 12596.0x30d8] Aborting fldigi due to a fatal error. Please report this to: fldigi-devel(a)sourceforge.net or file a bug report at: https://fedorahosted.org/fldigi/newticket ****** Stack trace: ****** Version information: fldigi 4.1.18 Copyright (C) 2007-2010 Dave Freese, Stelios Bounanos, and others. License GPLv3+: GNU GPL version 3 or later < http://www.gnu.org/licenses/gpl-3.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ****** Build information: Build information: built : Wed Mar 24 07:38:32 CDT 2021 by build(a)hobbes.localdomain on x86_64-redhat-linux-gnu for x86_64-w64-mingw32 configure flags: '--host=x86_64-w64-mingw32' '--build=x86_64-redhat-linux-gnu' '--target=x86_64-w64-mingw32' '--prefix=/usr/x86_64-w64-mingw32/sys-root/mingw' '--exec-prefix=/usr/x86_64-w64-mingw32/sys-root/mingw' '--bindir=/usr/x86_64-w64-mingw32/sys-root/mingw/bin' '--sbindir=/usr/x86_64-w64-mingw32/sys-root/mingw/sbin' '--sysconfdir=/usr/x86_64-w64-mingw32/sys-root/mingw/etc' '--datadir=/usr/x86_64-w64-mingw32/sys-root/mingw/share' '--includedir=/usr/x86_64-w64-mingw32/sys-root/mingw/include' '--libdir=/usr/x86_64-w64-mingw32/sys-root/mingw/lib' '--libexecdir=/usr/x86_64-w64-mingw32/sys-root/mingw/libexec' '--localstatedir=/usr/x86_64-w64-mingw32/sys-root/mingw/var' '--sharedstatedir=/usr/x86_64-w64-mingw32/sys-root/mingw/com' '--mandir=/usr/x86_64-w64-mingw32/sys-root/mingw/share/man' '--infodir=/usr/x86_64-w64-mingw32/sys-root/mingw/share/info' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-w64-mingw32' 'target_alias=x86_64-w64-mingw32' 'CXX=x86_64-w64-mingw32-g++' 'CXXFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4' 'LDFLAGS=-fstack-protector -lssp' 'CPPFLAGS=' 'CC=x86_64-w64-mingw32-gcc' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4' 'CPP=/usr/bin/x86_64-w64-mingw32-cpp' 'FLTK_CONFIG=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/fltk-config' 'PKG_CONFIG=/usr/bin/x86_64-w64-mingw32-pkg-config' compiler : gcc version 10.2.1 20200723 (Fedora MinGW 10.2.1-2.fc33) (GCC) compiler flags : -I$(srcdir) -I$(srcdir)/include -I$(srcdir)/irrxml -I$(srcdir)/libtiniconv -I$(srcdir)/fileselector -I$(srcdir)/xmlrpcpp -I$(srcdir)/mbedtls -mthreads -mthreads -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libusb-1.0 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libpng16 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -pipe -Wall -fexceptions -O2 --param=max-vartrack-size=0 -I$(srcdir)/xmlrpcpp --param=max-vartrack-size=0 -DNDEBUG linker flags : -mthreads -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lportaudio -lwinmm -lm -ldsound -lole32 -lwinmm -lm -luuid -lsetupapi -lole32 -lwinmm -lm -lole32 -luuid -lwinmm -lm -lole32 -luuid -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lfltk_images -lpng -lz -ljpeg -lfltk -lpthread -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lsndfile -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lsamplerate -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lhamlib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lpng16 -lz -lpthread -lwsock32 -lws2_32 libraries : FLTK 1.3.5 libsamplerate 0.1.9 libsndfile 1.0.28 PortAudio 19 Hamlib 3.3 Runtime information: system : windows32 DESKTOP-V44I0VT 2.6.2 9200 amd64 libraries : libsamplerate-0.1.9 (c) 2002-2008 Erik de Castro Lopo libsndfile-1.0.28 PortAudio V19.6.0-devel, revision 396fe4b6699ae929d3a685b3ef8a7e97396139a4 1246720 Hamlib 3.3 [Thread 12596.0x26dc exited with code 150] [Thread 12596.0x1ba8 exited with code 150] [Thread 12596.0x38a0 exited with code 150] [Thread 12596.0x4c8 exited with code 150] [Thread 12596.0x2478 exited with code 150] [Thread 12596.0x4048 exited with code 150] [Thread 12596.0x28dc exited with code 150] [Thread 12596.0xbc4 exited with code 150] [Thread 12596.0x3bc4 exited with code 150] [Thread 12596.0x3c54 exited with code 150] [Thread 12596.0x3f28 exited with code 150] [Thread 12596.0x3db0 exited with code 150] [Thread 12596.0x2570 exited with code 150] [Thread 12596.0xa90 exited with code 150] [Thread 12596.0x3838 exited with code 150] [Thread 12596.0x1e98 exited with code 150] [Thread 12596.0x1aec exited with code 150] [Thread 12596.0x30d8 exited with code 150] [Inferior 1 (process 12596) exited with code 0226] (gdb) thread apply all bt full (gdb) Thanks, Richard

1 0

Re: Merging mingw specs into native spec
by Richard W.M. Jones 03 Mar '21

03 Mar '21

On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote: > V Tue, Mar 02, 2021 at 12:45:42PM +0000, Richard W.M. Jones napsal(a): > > On Mon, Mar 01, 2021 at 01:31:13PM +0000, Daniel P. Berrangé wrote: > > > +%if %{_with_mingw} > > > + > > > +%package -n mingw32-libvirt-glib > > > +Summary: MingwGW Windows libvirt-gconfig virtualization library > > > +BuildArch: noarch > > > +Requires: pkgconfig > > > + > > Why are the packages noarch if they contain a machine code? Dan already noted that you can run the cross-compiler on any architecture. However it is a good question about why the final packages are "noarch". Windows these days only exists on i686, x86-64 and aarch64. I don't know what mingw-w64's support for aarch64 is like, but we only bother building i686 ("mingw32-*") and x86-64 ("mingw64-*") packages. Normally the end result is intended to be run on Windows, so it's "noarch" as far as Fedora is concerned. The normal deployment method is to use NSIS to generate an installer (from files in the RPMs you've installed locally) which is copied over to Windows. You can do this on any arch. But you can also run the code under Wine on an x86-64 host. Probably on i686 host but I doubt anyone has done that in a long while. Wine doesn't work on non-x86 arches. I don't think that Koji / RPM is really designed to cope with all this subtlety though. And implementing it just for mingw is way too much work. > Fullarch Linux packages are built on various architectures. Is MinGW > toolchain available on all of them? E.g if my Linux package builds > on s390x, is there a crosscompiler available and is thus possible to > build Windows binaries there? What about runnning tests in %check > phase? Yes, any build arch can be used. We don't usually run tests in %check because running Wine under Koji is a pain. It requires a specifically configured $HOME, and X server (even for console programs). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

1 0

Re: Merging mingw specs into native spec
by Daniel P. Berrangé 03 Mar '21

03 Mar '21

1 0

Re: Merging mingw specs into native spec
by Daniel P. Berrangé 02 Mar '21

02 Mar '21

On Tue, Mar 02, 2021 at 11:21:16AM -0500, Neal Gompa wrote: > On Tue, Mar 2, 2021 at 11:13 AM Greg Hellings <greg.hellings(a)gmail.com> wrote: > > > > > > > > On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones <rjones(a)redhat.com> wrote: > >> > >> [Adding the devel list, since this change would obviously affect > >> several "base" packages.] > >> > >> On Mon, Mar 01, 2021 at 01:31:13PM +0000, Daniel P. Berrangé wrote: snip > >> > In summary based on my tests I think killing off the separate dist-git > >> > / RPM spec for mingw looks feasible unless someone knows of hidden > >> > show stoppers I haven't hit yet. > >> > > >> > I think we should go ahead and do this for some packages to demonstrate > >> > the concept in the real world, and I'm volunteering to coordinate it for > >> > all the virtualization packages I'm involved in maint of because I can't > >> > even reliably keep them in sync myself. libvirt, libvirt-glib, libosinfo, > >> > osinfo-db-tools, gtk-vnc, spice-gtk all use meson, so should mirror the > >> > approach above and be quite easy. > >> > > >> > Once we can demonstrate the real world impact, we can socialize the idea > >> > on Fedora devel list more widely and then also approach maintainers > >> > of other native packages to attempt to convince them to accept mingw > >> > sub-RPMs into their specs. Every mingw package we can get merged into > >> > native package frees up a little more time for to spend on the remaining > >> > mingw packages that are still separate. Ideally we'd get 100% merged > >> > long term, but even if we get refusals from native maintainers, we'll > >> > still be better off with those we do succeed in merging. > >> > > >> > Regards, > >> > Daniel > >> > >> Sounds in general like a good idea, but I think we should make it > >> opt-in only for the foreseeable future. Some packagers won't > >> appreciate the extra overhead of all the mingw stuff. > > > > > > I, for one, welcome this. For several of the packages I maintain, I'm the only person to support them in both native and mingw biulds. > > > > Do you have a suggested path I would take to deprecate the mingw-foo packages once I roll over building them into the native package? > > > > I'm also happy about this. I think we should get some packages > converted in a COPR so we can see this more concretely. I think we can > also make some improvements here for this so that we don't have to do > weird overrides of RPM macros too by making adjustments to > redhat-rpm-config. If people have ideas on how to improve the standard macros to simplify mingw additions I'm all for it. > Can we have a COPR going soon to have some examples showing how this > works? Then I can take a look more concretely on how this works and > see if I can help make this smoother. Sure, I can do builds of a few of the virt packages in my copr to illustrate it Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

Merging mingw specs into native spec
by Daniel P. Berrangé 02 Mar '21

02 Mar '21

Way back when we first started the mingw project in Fedora we took the decision to maintain the mingw builds as separate source RPMs in Fedora. The rationale was that mingw support was a new concept to Fedora with many unknowns. We often had custom mingw only patches, and there was a decent chance there would be breakage upon rebases. We didn't want to burden the native package maintainers with mingw support as that would have increased pushback against the effort. This decision was always going to cause us problems with keeping the mingw dist-git packages in sync with native dist-git packages. This is especially important when it comes to security fixes, and there have been reasonably well justified complaints about mingw lagging native wrt to CVE fixing in recent times. Since the early days we merged the separate mingw32-$PKG / mingw64-$PKG source RPMS into a single mingw-$PKG in dist-git. The need for patching mingw RPMs to fix problems in Fedora doesn't seem any higher than the need for patching to fix native build problem. Generally things just work when rebasing, because most upstreams recognize the importance of keeping their projects working on mingw. IOW, we were afraid of a maintainer burden that has turned out to largely not exist. To address this non-existant burden, we intentionally made the maint of mingw packages harder than it needs to be in Fedora. This is a long winded way of saying I think it is time to update the mingw packaging guidelines to allow for, even recommend, mingw packaging to be a standard part of the native RPM spec. In doing so we eliminate the main burden of mingw packaging in Feora and guarantee that we'll always be up to date wrt bug/security fixes and rebases. I've done some basic tests with libvirt-glib upstream which recently changed to using Meson. Supporting mingw in the main libvirt-glib.spec was largely trivial. I simply needed to copy the various blocks of the mingw-libvirt-glib.spec file into the libvirt-glib.spec, ending up with a diff: diff --git a/libvirt-glib.spec.in b/libvirt-glib.spec.in index 58e6242..81f972b 100644 --- a/libvirt-glib.spec.in +++ b/libvirt-glib.spec.in @@ -1,5 +1,15 @@ # -*- rpm-spec -*- +%bcond_without mingw + +%define _with_mingw 0 +%if 0%{?fedora} +%define _with_mingw 0%{with mingw} +%endif + +%define mingw32_pkg_name mingw32-%{name} +%define mingw64_pkg_name mingw64-%{name} + Name: libvirt-glib Version: @VERSION@ Release: 1%{?dist} @@ -16,6 +26,16 @@ BuildRequires: libxml2-devel BuildRequires: vala-tools BuildRequires: gettext +%if %{_with_mingw} +BuildRequires: mingw32-filesystem +BuildRequires: mingw64-filesystem +BuildRequires: mingw32-glib2 +BuildRequires: mingw64-glib2 +BuildRequires: mingw32-libvirt +BuildRequires: mingw64-libvirt +%endif + + %package devel Summary: libvirt glib integration for events development files Requires: %{name} = %{version}-%{release} @@ -37,6 +57,42 @@ Requires: libvirt-gconfig-devel = %{version}-%{release} Requires: libvirt-gobject = %{version}-%{release} Requires: libvirt-devel + +%if %{_with_mingw} + +%package -n mingw32-libvirt-glib +Summary: MingwGW Windows libvirt-gconfig virtualization library +BuildArch: noarch +Requires: pkgconfig + +%package -n mingw32-libvirt-gconfig +Summary: MingwGW Windows libvirt-gconfig virtualization library +BuildArch: noarch +Requires: pkgconfig + +%package -n mingw32-libvirt-gobject +Summary: MingwGW Windows libvirt-gobject virtualization library +BuildArch: noarch +Requires: pkgconfig + +%package -n mingw64-libvirt-glib +Summary: MingwGW Windows libvirt-gconfig virtualization library +BuildArch: noarch +Requires: pkgconfig + +%package -n mingw64-libvirt-gconfig +Summary: MingwGW Windows libvirt-gconfig virtualization library +BuildArch: noarch +Requires: pkgconfig + +%package -n mingw64-libvirt-gobject +Summary: MingwGW Windows libvirt-gobject virtualization library +BuildArch: noarch +Requires: pkgconfig + +%endif + + %description This package provides integration between libvirt and the glib event loop. @@ -61,6 +117,31 @@ objects This package provides development header files and libraries for managing virtualization host objects +%if %{_with_mingw} + +%description -n mingw32-libvirt-glib +MinGW Windows libvirt-glib virtualization library. + +%description -n mingw32-libvirt-gconfig +MinGW Windows libvirt-gconfig virtualization library. + +%description -n mingw32-libvirt-gobject +MinGW Windows libvirt-gobject virtualization library. + + +%description -n mingw64-libvirt-glib +MinGW Windows libvirt-glib virtualization library. + +%description -n mingw64-libvirt-gconfig +MinGW Windows libvirt-gconfig virtualization library. + +%description -n mingw64-libvirt-gobject +MinGW Windows libvirt-gobject virtualization library. + +%{?mingw_debug_package} +%endif + + %prep %setup -q @@ -68,11 +149,23 @@ managing virtualization host objects %meson -Drpath=disabled %meson_build +%if %{_with_mingw} +%mingw_meson -Drpath=disabled -Ddocs=disabled +%mingw_ninja +%endif + %install %meson_install %find_lang %{name} +%if %{_with_mingw} +%mingw_ninja_install + +%mingw_find_lang libvirt-glib +%mingw_debug_install_post +%endif + %check %meson_test @@ -140,4 +233,87 @@ managing virtualization host objects %{_datadir}/vala/vapi/libvirt-gobject-1.0.deps %{_datadir}/vala/vapi/libvirt-gobject-1.0.vapi + +%if %{_with_mingw} + +%files -n mingw32-libvirt-glib -f mingw32-libvirt-glib.lang +%doc README COPYING AUTHORS NEWS +%{mingw32_bindir}/libvirt-glib-1.0-0.dll + +%{mingw32_libdir}/libvirt-glib-1.0.dll.a + +%{mingw32_libdir}/pkgconfig/libvirt-glib-1.0.pc + +%dir %{mingw32_includedir}/libvirt-glib-1.0 +%dir %{mingw32_includedir}/libvirt-glib-1.0/libvirt-glib +%{mingw32_includedir}/libvirt-glib-1.0/libvirt-glib/libvirt-glib.h +%{mingw32_includedir}/libvirt-glib-1.0/libvirt-glib/libvirt-glib-*.h + +%files -n mingw64-libvirt-glib -f mingw64-libvirt-glib.lang +%doc README COPYING AUTHORS NEWS +%{mingw64_bindir}/libvirt-glib-1.0-0.dll + +%{mingw64_libdir}/libvirt-glib-1.0.dll.a + +%{mingw64_libdir}/pkgconfig/libvirt-glib-1.0.pc + +%dir %{mingw64_includedir}/libvirt-glib-1.0 +%dir %{mingw64_includedir}/libvirt-glib-1.0/libvirt-glib +%{mingw64_includedir}/libvirt-glib-1.0/libvirt-glib/libvirt-glib.h +%{mingw64_includedir}/libvirt-glib-1.0/libvirt-glib/libvirt-glib-*.h + + + +%files -n mingw32-libvirt-gconfig +%{mingw32_bindir}/libvirt-gconfig-1.0-0.dll + +%{mingw32_libdir}/libvirt-gconfig-1.0.dll.a + +%{mingw32_libdir}/pkgconfig/libvirt-gconfig-1.0.pc + +%dir %{mingw32_includedir}/libvirt-gconfig-1.0 +%dir %{mingw32_includedir}/libvirt-gconfig-1.0/libvirt-gconfig +%{mingw32_includedir}/libvirt-gconfig-1.0/libvirt-gconfig/libvirt-gconfig.h +%{mingw32_includedir}/libvirt-gconfig-1.0/libvirt-gconfig/libvirt-gconfig-*.h + +%files -n mingw64-libvirt-gconfig +%{mingw64_bindir}/libvirt-gconfig-1.0-0.dll + +%{mingw64_libdir}/libvirt-gconfig-1.0.dll.a + +%{mingw64_libdir}/pkgconfig/libvirt-gconfig-1.0.pc + +%dir %{mingw64_includedir}/libvirt-gconfig-1.0 +%dir %{mingw64_includedir}/libvirt-gconfig-1.0/libvirt-gconfig +%{mingw64_includedir}/libvirt-gconfig-1.0/libvirt-gconfig/libvirt-gconfig.h +%{mingw64_includedir}/libvirt-gconfig-1.0/libvirt-gconfig/libvirt-gconfig-*.h + + + +%files -n mingw32-libvirt-gobject +%{mingw32_bindir}/libvirt-gobject-1.0-0.dll + +%{mingw32_libdir}/libvirt-gobject-1.0.dll.a + +%{mingw32_libdir}/pkgconfig/libvirt-gobject-1.0.pc + +%dir %{mingw32_includedir}/libvirt-gobject-1.0 +%dir %{mingw32_includedir}/libvirt-gobject-1.0/libvirt-gobject +%{mingw32_includedir}/libvirt-gobject-1.0/libvirt-gobject/libvirt-gobject.h +%{mingw32_includedir}/libvirt-gobject-1.0/libvirt-gobject/libvirt-gobject-*.h + +%files -n mingw64-libvirt-gobject +%{mingw64_bindir}/libvirt-gobject-1.0-0.dll + +%{mingw64_libdir}/libvirt-gobject-1.0.dll.a + +%{mingw64_libdir}/pkgconfig/libvirt-gobject-1.0.pc + +%dir %{mingw64_includedir}/libvirt-gobject-1.0 +%dir %{mingw64_includedir}/libvirt-gobject-1.0/libvirt-gobject +%{mingw64_includedir}/libvirt-gobject-1.0/libvirt-gobject/libvirt-gobject.h +%{mingw64_includedir}/libvirt-gobject-1.0/libvirt-gobject/libvirt-gobject-*.h + +%endif + %changelog Some notes: * We need to set mingw32_pkg_name/mingw64_pkg_name explicitly because the current logic that sets these doesn't work: %mingw32_pkg_name %(echo %{name} | sed 's/^mingw-/mingw32-/') Presumably we can fix that macro so that it does the right thing when no mingw- prefix exists in the first place * We can't use %mingw_package_header because that splatters the native debuginfo generation. So we must explicitly add mingw debuginfo packages by referencing %{?mingw_debug_package} and at end of %install add %mingw_debug_install_post * %mingw_package_header has reference to overriding strip/objdump to prevent corruption of binaries. We can't do that override because we need native strip/objdump for the native builds. AFAICT though, no corruption happened to my DLLs even without this strip/objdump override. Looks like this caveat might be obsolete, unless the scenarios it hits are more niche than I tested. * %mingw_package_header tries to disable the internal dependancy generator on RHEL 6. For reasons I don't understand, it ends up disabling it on Fedora too. %mingw_package_header \ %global __strip %{mingw_strip} \ %global __objdump %{mingw_objdump} \ %if 0%{?rhel} == 6 \ %global _use_internal_dependency_generator 0 \ %global __find_requires %{mingw_findrequires} \ %global __find_provides %{mingw_findprovides} \ %endif \ %global __debug_install_post %%{mingw_debug_install_post} \ %{nil} Those three %global inside the rhel conditional *do* get evaluated on Fedora. We can see this in the old build logs in fact https://kojipkgs.fedoraproject.org/packages/mingw-libvirt-glib/4.0.0/1.fc35… warning: Deprecated external dependency generator is used! Finding Provides: /usr/lib/rpm/mingw-find-provides.sh mingw32 mingw64 .... When I hack macros.mingw to remove the dep generator override code entirely, almost everything still seems to work. rpm's built-in dep generator still adds the mingw32(libssp-0.dll) virtual deps. The only thing that gets lost is the dep on mingw-pkg-config IOW it looks like RPMs built-in dep generator pretty much does the right thing. Just need to add a manual mingw-pkg-config dep * Converting meson packages was easy because meson always uses a separate build dir. Many autoconf based packages default to building in the source dir. The first step would thus have to be to make the native build use a separate build dir. In theory this should be easy as mingw autoconf macros are already doing this, but I always expect dragons with autoconf. In summary based on my tests I think killing off the separate dist-git / RPM spec for mingw looks feasible unless someone knows of hidden show stoppers I haven't hit yet. I think we should go ahead and do this for some packages to demonstrate the concept in the real world, and I'm volunteering to coordinate it for all the virtualization packages I'm involved in maint of because I can't even reliably keep them in sync myself. libvirt, libvirt-glib, libosinfo, osinfo-db-tools, gtk-vnc, spice-gtk all use meson, so should mirror the approach above and be quite easy. Once we can demonstrate the real world impact, we can socialize the idea on Fedora devel list more widely and then also approach maintainers of other native packages to attempt to convince them to accept mingw sub-RPMs into their specs. Every mingw package we can get merged into native package frees up a little more time for to spend on the remaining mingw packages that are still separate. Ideally we'd get 100% merged long term, but even if we get refusals from native maintainers, we'll still be better off with those we do succeed in merging. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw March 2021