And currently blocking Cabal CI because alex --version segfaults.
It also so happens that I build the alpine 32bit GHC variant for every single release manually.
I think it’s beyond reasonable by now and I’m considering to drop it in GHCup at least, unless some volunteers step up and want to investigate those issues in GHC.
Sure, it might be more an issue of musl + 32bit and we could at least attempt to provide glibc binaries, even if they’re less portable.
We still have 32bit Intel Haskell built in Fedora - primarily because of Pandoc, but also cos it mostly seems to work - I doubt any of our users are actually using it though since we don’t ship it! There are certainly a few problems from time to time but overall in glibc land it still seems to work okay or build at least: a few packages are excluded (eg Agda).
(Not sure if/when we might drop ix86 in Fedora completely (it’s the only 32bit arch we still build userspace for), but not any time soon I guess since it is used for multiarch (people have tried to propose it - gaming is the main blocker;-), though building for it is optional now, but most packages still do. I think Debian still builds for i386 too. Hth a little for distro perspective.)
Is this question specifically about i386 or more broadly 32-bit architectures?
I’d be okay if modern GHC versions dropped support for i386, when at least old bindists (and tooling!) were still around to be downloaded from somewhere, e.g. the distro’s package manager. As long as the distro supports the arch, that is.
Actually read this post first on a 32-bit i686 netbook, where I can’t update stack due to #5589.
I often use i386 to test a 32 bit arch in CI. I can’t remember having any problems with it. In my opinion, there should be at least one 32 bit platform that is somewhat easy to set up for CI.