GHC 9.6.1 is now available

Announcements
#1

The GHC team is very pleased to announce the availability of GHC 9.6.1.
As usual, binaries and source distributions are available at
downloads.haskell.org.

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to
WebAssembly and JavaScript. This is an important step towards robust
support for compiling Haskell to the Web, but there are a few caveats to be
aware of in the 9.6 series:

  • Both the Javascript and WebAssembly backends are still at an early
    stage of development and are present in this release as a technology preview

  • Using GHC as a cross-compiler is not as easy as we would like it to
    be; in particular, there are challenges related to Template Haskell

  • GHC is not yet run-time retargetable; a given GHC binary targets
    exactly one platform, and both WebAssembly and JavaScript are considered
    platforms for this purpose. Cross-compilers must be built from source by
    their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 includes:

  • Significant latency improvements in the non-moving garbage collector

  • Efficient runtime support for delimited continuations

  • Improvements in compiler error messages

  • Numerous improvements in the compiler’s memory usage

See the release notes for a comprehensive accounting of changes in this
release.

As always, one can find a migration guide to aid in transitioning from older
releases on the GHC Wiki. We have also recently started
extending our release process to cover a wider set of Linux distributions. In
particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which
cover RedHat-derivative and distributions using older glibc releases (namely
2.27), respectively.

Thanks to everyone who has contributed code, documentation, testing, and
tickets to this release process. As this release represents upstream GHC’s
first step towards supporting web targets, we are very excited to have this
release out the door!

Cheers,

  • Ben
38 Likes
#2

Unofficial FreeBSD bindist (with native gmp backend, because there seems to be a hadrian bug when building with libgmp): Index of /ghcup/unofficial-bindists/ghc/9.6.1/

metadata updated: Add GHC 9.6.1 proper · haskell/ghcup-metadata@c58f03c · GitHub

5 Likes
#3

I have updated Stack’s default setup-info dictionary for these binary distributions, and added GHC 9.6.1’s global hints to global-hints.yaml . (As there is no ‘Fedora 27’ version of GHC 9.6.1, Stack uses the ‘Debian 10’ version for Linux/x86_64 systems where tinfo6 is present and the libc6 version is pre-2.32.)

3 Likes
#4

The fedora substitute is Rocky8, which is more portable.

2 Likes
#5

In that case, I’ll change Stack’s default setup-info to refer to the ‘Rocky 8’ version of GHC 9.6.1 where it would have referred to the ‘Fedora 27’ version.

2 Likes
#6

Why is Rocky 8 more portable than Debian 10?

The Rocky 8 build used binutils 2.30, Debian 10 used binutils 2.26.

The other versions are the same according to that table.

Given that the Debian 10 version is older, wouldn’t that mean that the Debian 10 build is more portable?

1 Like
#7

Debian messes with libraries and spams stderr of GHC on non-debian distributions, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1875587

That is part of “portability” too.

3 Likes
#8

Forgive me if this is a stupid question but how would I go about using GHC 9.6.1 in a project that uses Stack to produce a JavaScript artifact?

Pre the release of 9.6.1 I did compile GHC from source and was able to translate a single very simple Haskell script into a node runnable artifact but I have no idea how to use this compiler to compile an actual project – Cabal, Stack, or otherwise.

Any suggestions or advice greatly appreciated. Nothing is too obvious to mention, ie TMLI5.

1 Like
#9

Since there are different ghc binaries for different linux distributions, I assume ghc links against the libraries in the list already linked by @hasufell. Are these libraries really all required? I don’t know, but could it be that gcc, binutils, glibc and tinfo are needed for the C compiler backend? Maybe they are obsolete, since ghc now uses LLVM. Also ncurses might be statically linked, since it has the X11 License. Maybe there could be a single binary for all distributions?

1 Like
#10

There are problems with using fully static bindists with cabal though. Feel free to try.

1 Like
#11

From what I understand you’ll still need to

  1. compile a specific version of GHC-9.6.1 yourself that is targeted to produce javascript output
  2. tell stack to use your specific version of ghc. You can do so by setting system-ghc: yes in your stack.config file, and
  3. making sure that the path to ghc (i.e. the “system-ghc” as considered by stack) is your particular build of ghc that produces javascript.

(and then “simply” call stack build on your project).

I believe the plan/hope is to have some sort of flag in ghc-9.8 that you can set to produce javascript output rather than having to recompile a specific version of ghc from scratch to do so.

3 Likes
#12

If you are using GHC 9.6.1 on Windows with a dependency on the network package, you will need to bump to the newly-released network-3.1.2.9 to avoid a glitch.

1 Like
#13

Thanks for this fix! This was a tricky one: Don't declare `_GNU_SOURCE` on Windows · Issue #551 · haskell/network · GitHub