# GHC 9.4.2 is now available

**URL:** <https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955>\
**Category:** Announcements\
**Created:** [August 22, 2022, 6:55pm UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955 "2022-08-22T18:55:10Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [August 22, 2022, 6:55pm UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/1 "2022-08-22T18:55:10Z")

</div>

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](https://downloads.haskell.org/ghc/9.4.2).

This release is primarily a bugfix release addressing a few packaging issues  
found in 9.4.1. See the [release notes](https://downloads.haskell.org/~ghc/9.4.2/docs/users_guide/9.4.2-notes.html) 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](https://gitlab.haskell.org/ghc/ghc/-/issues/new). Likewise, if you are a downstream  
packager, do consider migrating to [Hadrian](https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian) to run your build; the Hadrian  
build system can be built using `cabal-install`, `stack`, or the in-tree  
[bootstrap script](https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md). See the accompanying [blog post](https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html) 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](https://gitlab.haskell.org/ghc/ghc/-/issues/new) if you see  
anything amiss.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [August 26, 2022, 12:40am UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/2 "2022-08-26T00:40:47Z")

</div>

> <https://github.com/haskell/ghcup-metadata/commit/f013568183083d6b349fa2b59d7d6f3960689d61>

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [August 26, 2022, 12:28pm UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/3 "2022-08-26T12:28:12Z")

</div>

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’.)

---

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [August 27, 2022, 2:35am UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/4 "2022-08-27T02:35:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [August 28, 2022, 3:28pm UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/5 "2022-08-28T15:28:02Z")

</div>

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](https://iohk.io/en/blog/posts/2020/07/28/improving-haskells-big-numbers-support/)). 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.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [August 29, 2022, 2:24am UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/6 "2022-08-29T02:24:33Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [August 29, 2022, 9:15pm UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/7 "2022-08-29T21:15:47Z")

</div>

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](https://github.com/commercialhaskell/stackage-content/issues/108) and [https://github.com/commercialhaskell/stackage-content/issues/111](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](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.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [August 30, 2022, 8:30am UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/8 "2022-08-30T08:30:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [September 1, 2022, 11:04pm UTC](https://discourse.haskell.org/t/ghc-9-4-2-is-now-available/4955/9 "2022-09-01T23:04:36Z")

</div>

[Index of /ghc/latest/](https://downloads.haskell.org/ghc/latest) still links to 9.4.1, and not to 9.4.2. I suspect this may be in error?