Fix #118 Add bindists for GHC 9.4.3

[mpilgrem]

Follows the approach taken to date for GHC 9.4.1 and GHC 9.4.2.

[ysangkok]

The script in #122 also passes for this (after adjusting the version):

passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-i386-deb9-linux.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-i386-deb9-linux.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-deb9-linux.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-deb9-linux.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-fedora33-linux.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-fedora33-linux.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-apple-darwin.tar.bz2
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-apple-darwin.tar.bz2
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-aarch64-apple-darwin.tar.bz2
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-aarch64-apple-darwin.tar.bz2
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-unknown-mingw32-int_native.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-unknown-mingw32-int_native.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-unknown-mingw32-int_native.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-unknown-mingw32-int_native.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-unknown-mingw32.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-x86_64-unknown-mingw32.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-aarch64-deb10-linux.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-aarch64-deb10-linux.tar.xz
passed check sha1 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-aarch64-deb10-linux.tar.xz
passed check sha256 https://downloads.haskell.org/~ghc/9.4.3/ghc-9.4.3-aarch64-deb10-linux.tar.xz

[mpilgrem]

@mihaimaruseac, many thanks. My pause here is wondering about the implication of #117. In short, some people have said picking 'Fedora 33 GHC' as Linuix/x86_64/tinfo6 is problematic because of its libc6 version. I've wondered (in #117) if the solution is picking 'Debian 10 GHC' as an alternative. However, it has been separately suggested that 'Debian 10 GHC' is somehow irksome for non-Debian/non-Ubuntu Linux users. For better or worse, I am a Windows user and so I can't contribute to that discussion by drawing on personal experience. I don't know which is the 'lesser evil' for most Linux users - 'Fedora 33 GHC' or 'Debian 10 GHC'. If you (or any Linux users reading this) can help bring that to a resolution, that would be much appreciated.

[mihaimaruseac]

I think Debian will work better with Stackage nightly (which is why I approved this). But probably @juhp can speak about the Fedora case

[juhp]

Maybe @hasufell has some more insight on this?

(I actually opened a wordy ghc ticket recently asking about the fedora33 bindist choice. (Of course f33 is totally fine for Fedora (it basically means a RHEL9 base) but I think debian10 would be more portable overall - I haven't actually tried debian10 on RHEL8 say though I expect it should work.))

Can these mapping be adjusted later if needed?

I think ideally stack should choose the bindist depending on the Linux distro being used, but I guess that is nontrivial to implement.

[hasufell]

Maybe @hasufell has some more insight on this?

but I think debian10 would be more portable overall

This is where I disagree. I consider debian not portable. Their downstream patches sometimes cause problems, or the way they build libraries.

https://bugzilla.redhat.com/show_bug.cgi?id=1875587

There was a prominent case where they broke Skype for other distros, because they're even messing with SONAMEs sometimes: https://bugs.gentoo.org/415985

[mpilgrem]

I am going to merge this, which follows what Stack originally did for GHC 9.4.1 and GHC 9.4.2, and if something needs fixing (#117 or some other permutation) then it can be applied to all of GHC 9.4.1 to GHC 9.4.3.

[juhp]

It might be that centos7 is a better default bindist choice for Linux?
At least I see on RHEL8 that ghcup causes the centos7 bindists of 9.2.5 and 9.4.3 to be installed.

[juhp]

So also in the Stackage build server environment we are still using Ubuntu 20.04 and the current default 9.4.3 tarball gives

/var/stackage/.stack/programs/x86_64-linux/ghc-tinfo6-9.4.3/lib/ghc-9.4.3/bin/ghc-pkg: /lib/x86_64-linux-gnu/libc.so.6: version `GLI
BC_2.32' not found (required by /var/stackage/.stack/programs/x86_64-linux/ghc-tinfo6-9.4.3/lib/ghc-9.4.3/bin/../lib/x86_64-linux-gh
c-9.4.3/libHSrts-1.0.2-ghc9.4.3.so)

So it might be better to change to centos7, even though that is an older platform than fedora27 (which was roughly rhel/centos 8). I guess it needs testing, no sure about gmp for example.

[juhp]

https://gitlab.haskell.org/ghc/ghc/-/issues/22268 is the upstream ticket with related discussion

[juhp]

This also broke Stackage CI in github, but we have worked around it by moving the CI action to use Ubuntu 22.04.

(On the Stackage buildserver I worked around it by manually installing the debian10 bindist by hand into our Ubuntu 20.04 build container environment.)

Also noting that latest Stackage Nightly is now on ghc-9.4.3.