Getting useful gdb output
by Richard Shaw
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
3 years
- 1
- 0
Re: Merging mingw specs into native spec
by Richard W.M. Jones
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
3 years, 1 month
- 1
- 0
Re: Merging mingw specs into native spec
by Daniel P. Berrangé
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?
>
> 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?
The mingw toolchain is a cross compiler, and available on all Fedora
arches, so it doesn't matter what arch we build the DLLs on. Generally
we dont run tests in %check for mingw, but in theory you could use
wine to do this.
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 :|
3 years, 1 month
- 1
- 0
Re: Merging mingw specs into native spec
by Daniel P. Berrangé
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 :|
3 years, 1 month
- 1
- 0
Merging mingw specs into native spec
by Daniel P. Berrangé
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.fc...
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 :|
3 years, 1 month
- 4
- 4
- ← Newer
- 1
- Older →