EPEL support
by Michael Cronenworth
The MinGW packages for EPEL 7 are in a very bad state. We haven't even started on
EPEL 8 yet.
Should we discontinue support for EPEL?
Does anyone have any use case for EPEL?
I'm going to retire my EPEL branches, but if anyone wants to take them over please
go ahead.
Thanks,
Michael
4 years, 3 months
Re: EPEL support
by Michael Cronenworth
On 8/24/19 6:47 PM, Marco Feenstra wrote:
> Is this Erik van Pienbroeks legacy?
Yes, he maintained the core packages in EPEL and I maintained PostgreSQL. No one has
taken it over.
4 years, 3 months
mingw-rust and mingw32, SJLJ vs dwarf2 exception model
by Sandro Mani
Hi
I've got a working build of mingw64-rust [1] with which I'm able to
successfully build a current version of mingw64-librsvg2. But here comes
the problem: As explained here [2], rust cannot be cross-compiled to a
mingw32 target using SJLJ exceptions. To be able to offer mingw-rust in
the main repos, I don't see many other options than switching the
mingw32 toolchain to dwarf2 exceptions if we want to keep the same
package set for both mingw32 and mingw64.
As far as I can see, there are some (rather old) discussions here and
there concerning which model to use, i.e. this one for debian [3] and
this one for mingw-w64 [4]. All in all, the summary appears to be
SJLJ (setjmp/longjmp):
- not "zero-cost": even if an exception isn't thrown, it incurs a minor
performance penalty (~15% in exception heavy code)
- allows exceptions to traverse through e.g. windows callbacks
DWARF (DW2, dwarf-2)
- no permanent runtime overhead
- needs whole call stack to be dwarf-enabled, which means exceptions
cannot be thrown over e.g. Windows system DLLs (i.e. throwing an
exception in a system DLL callback and attempting to catch it won't work)
- DW2 potentially generates bigger libraries. The overhead however is
not big (< 10%) for typical applications.
MSYS2 for one appears to have switched to DW2 [5].
Any opinions whether we should also switch to dwarf2? Or how to handle
the mingw-rust situation in general?
Thanks
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw64-rust/builds/
[2] https://github.com/rust-lang/rust/issues/12859
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540782
[4] https://sourceforge.net/p/mingw-w64/mailman/message/30532139/
[5]
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUIL...
4 years, 3 months
MinGW bug reports
by Michael Cronenworth
Hi,
Thanks for creating something that creates bug reports.
I used to send emails to the Fedora MinGW mailing list that would report the same data.
Could you send an email to the Fedora MinGW mailing list with a master list of
package names, versions, and owners? It would also be a good time to introduce
yourself there.
Thanks,
Michael
4 years, 3 months
Fwd: mingw-filesystem: redhat-rpm-config dependency
by Jakub Janku
I copied the wrong address. Forwarding to the proper one, sorry about that.
---------- Forwarded message ---------
From: Jakub Janku <jjanku(a)redhat.com>
Date: Mon, Aug 5, 2019 at 11:15 AM
Subject: mingw-filesystem: redhat-rpm-config dependency
To: <mingw-owner(a)lists.fedoraproject.org>
Hi,
the phodav's Windows build on Fedora Rawhide started to fail recently [0].
The cause seem to be the %{__global_cflags} and %{__global_ldflags}
macros (used in mingw-meson), that do not get evaluated properly as
the redhat-rpm-config package that provides them is missing.
Therefore I was wondering whether mingw-filesystem should require this package.
Apart from that, the aforementioned macros are marked as deprecated in
the source file [1].
[0] https://gitlab.gnome.org/GNOME/phodav/-/jobs/364344
[1] https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/macros
Cheers,
Jakub Janků
4 years, 3 months
