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/PKGBUILD#L...
In 2019, is there any reason to just not ship a 32-bit Windows binary? Does anyone still use non-64-bit Windows?
--Greg
On Mon, Aug 12, 2019 at 9:07 AM Sandro Mani manisandro@gmail.com wrote:
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/PKGBUILD#L... _______________________________________________ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org
On 8/12/19 9:11 AM, Greg Hellings wrote:
In 2019, is there any reason to just not ship a 32-bit Windows binary? Does anyone still use non-64-bit Windows?
The problem isn't with us or with MinGW. There's still plently of third-party, closed source 32-bit only applications that require a full 32-bit runtime. It will be a decade or more before we can finally say goodbye to 32-bit.
@Sandro, I have no hard objection to switching to DW2, but I have no objection either to dropping the 32-bit package. There shouldn't be many users of rust requiring 32-bit runtimes.
On Mon, Aug 12, 2019 at 7:22 PM Michael Cronenworth mike@cchtml.com wrote:
On 8/12/19 9:11 AM, Greg Hellings wrote:
In 2019, is there any reason to just not ship a 32-bit Windows binary?
Does anyone
still use non-64-bit Windows?
The problem isn't with us or with MinGW. There's still plently of third-party, closed source 32-bit only applications that require a full 32-bit runtime. It will be a decade or more before we can finally say goodbye to 32-bit.
@Sandro, I have no hard objection to switching to DW2, but I have no objection either to dropping the 32-bit package. There shouldn't be many users of rust requiring 32-bit runtimes.
This is what I meant - not dropping the mingw32 toolchain. Sorry for the confusion.
--Greg
On 13.08.19 06:03, Greg Hellings wrote:
On Mon, Aug 12, 2019 at 7:22 PM Michael Cronenworth <mike@cchtml.com mailto:mike@cchtml.com> wrote:
On 8/12/19 9:11 AM, Greg Hellings wrote: > In 2019, is there any reason to just not ship a 32-bit Windows binary? Does anyone > still use non-64-bit Windows? The problem isn't with us or with MinGW. There's still plently of third-party, closed source 32-bit only applications that require a full 32-bit runtime. It will be a decade or more before we can finally say goodbye to 32-bit. @Sandro, I have no hard objection to switching to DW2, but I have no objection either to dropping the 32-bit package. There shouldn't be many users of rust requiring 32-bit runtimes.This is what I meant - not dropping the mingw32 toolchain. Sorry for the confusion.
You have the problem what to do with packages which require rust, currently librsvg2. Without a mingw32-rust, I'd also need to drop mingw32-librsvg2, and all mingw32-* packages depending on it, or split the actual librsvg2 package into a mingw32-librsvg2 package which will stay frozen at version 2.40.19 (resp. the last version prior to rust being required), and a mingw64-librsvg2 which will follow the latest releases. But if more libraries pick up a rust requirement, this may become impractical, for both users and other packages, say for instance if a library interface changes and you'd need to handle the mingw32- and mingw64- case separately in dependent packages.
Sandro
On 13.08.19 10:31, Sandro Mani wrote:
You have the problem what to do with packages which require rust, currently librsvg2. Without a mingw32-rust, I'd also need to drop mingw32-librsvg2, and all mingw32-* packages depending on it, or split the actual librsvg2 package into a mingw32-librsvg2 package which will stay frozen at version 2.40.19 (resp. the last version prior to rust being required), and a mingw64-librsvg2 which will follow the latest releases. But if more libraries pick up a rust requirement, this may become impractical, for both users and other packages, say for instance if a library interface changes and you'd need to handle the mingw32- and mingw64- case separately in dependent packages.
Since no-one seems opposed, I've moved ahead and filed a change proposal [1].
Sandro
-
Greg Hellings -
Michael Cronenworth -
Sandro Mani