GHC 9.4.2 is now available

Announcements
#1

The GHC developers are happy to announce the availability of GHC 9.4.2. Binary
distributions, source distributions, and documentation are available at
downloads.haskell.org.

This release is primarily a bugfix release addressing a few packaging issues
found in 9.4.1. See the release notes for a full accounting.

Note that, as GHC 9.4 is the first release series where the release artifacts
are all generated by our new Hadrian build system, it is possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a ticket. Likewise, if you are a downstream
packager, do consider migrating to Hadrian to run your build; the Hadrian
build system can be built using cabal-install, stack, or the in-tree
bootstrap script. See the accompanying blog post for details on
migrating packaging to Hadrian.

We would also like to emphasize that GHC 9.4 must be used in conjunction with
Cabal-3.8 or later. This is particularly important for Windows users due to
changes in GHC’s Windows toolchain.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
other anonymous contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years. Finally,
this release would not have been possible without the hundreds of open-source
contributors whose work comprise this release.

As always, do give this release a try and open a ticket if you see
anything amiss.

19 Likes
#2
2 Likes
#3

May I ask, what is the difference between https://downloads.haskell.org/~ghc/9.4.2/ (with the tilde before ghc) and https://downloads.haskell.org/ghc/9.4.2/ (without the tilde)? Is one URL to be preferred over the over, for current usage? (EDIT: The reason for this odd question is that, in updating Stack’s default setup-info, I noticed it was using ~ghc URLs while the announcement was using just ghc URLs. I would like to make sure Stack is doing the ‘right thing’.)

1 Like
#4

Indeed they are identical; we don’t plan on retiring either although I think ~ghc is technically a legacy path.

#5

With the provision of the int_native bindists for the GHC 9.4 series, may I double check what are the plans (if any) of the GHC developers to provide integer-simple bindists for GHC >= 9.4.1?

I understand that the performance of the Haskell-native big-integer backend is better than integer-simple (from this article). So, I had assumed that separate integer-simple bindists were a thing of the past now that the int_native bindists were being published.

I was, however, confused by this entry on the GHC 9.4.2 download web pages (similarly for GHC 9.0.2/9.2.1/9.2.2/9.2.3/9.2.4/9.4.1 download web pages):

Alpine (GMP bignum implementation)

Alpine Linux 3.12 for x86-64. This is a complete build, including interactive system, profiling libraries and documentation. Unlike our other binary distributions, this links against the integer-simple big-integer backend and therefore does not require libgmp.

It looks to me like this text is a typographical error - that the ‘GMP’ heading is correct, but the descriptive narrative is not accurate.

#6

@mpilgrem may I also suggest that we synchronize which bindists we pick?

  1. ghcup decided to pick int_native for alpine bindists
  2. both choco and ghcup pick non-int_native for windows

That may reduce friction wrt HLS and ABI.

2 Likes
#7

EDIT: I should have started by saying that I am all for a co-ordinated approach to things.

To clarify, in Stack’s default setup-info YAML configuration file:

  • plain/standard windows64 points to the GMP variant, and that will remain the case. That is consistent with Choco and GHCup;

  • historically, Stack’s default has not made use of any of the ‘alpine’ GHC variants. So, in that sense, Stack/Alpine would be starting from a blank sheet; and

  • historically, Stack has also provided a windows64-integersimple variant.

How best to handle the ‘integer-simple’ to ‘int-native’ development in Stack is being discussed at https://github.com/commercialhaskell/stackage-content/issues/108 and https://github.com/commercialhaskell/stackage-content/issues/111.

The introduction of int_native will need some rewiring of Stack’s innards (which is being dealt with at https://github.com/commercialhaskell/stack/pull/5834).

For that reason, people still on Stack 2.7.5 binaries will need to be accomodated. My plan was, for GHC >= 9.4.1, to have Stack treat integersimple as a synonym for int-native for those users, but that requires integer-simple to be history, from GHC 9.4.1 onward. The question I asked above was to confirm (or otherwise) that integer-simple GHC bindists are a thing of the past, from GHC 9.4.1 onwards.

1 Like
#8

@hsyl20 has kindly answered my question above, on the Stackage Content repository - integer-simple has been fully removed and won’t come back.

#9

Index of /ghc/latest/ still links to 9.4.1, and not to 9.4.2. I suspect this may be in error?

1 Like