Build release archives (and validate) with GHC 9.2.3

[Mikolaj]

Fixes #8271.

Do we need this in a changelog? I guess not, just as we don't file CI changes? Though this one is user-visible, namely for the users of our binary archives.

[Mikolaj]

So far, so good. I've pushed tag test-tag-build-with-ghc-9 to check how gitlab reacts here https://gitlab.haskell.org/haskell/cabal/-/pipelines/ and so far no reaction, but it's normal, it probably syncs once half an hour or so.

[ulysses4ever]

As it is user-visible (or, at least, user-sensible), I’d think changelog may make sense. But I defer to your judgement. I am also wondering how possible that this switch breaks something. If it will, though, it will probably be subtle, and a changelog will hardly help.

[Mikolaj]

@hasufell: do I read it right that GHC 9.2.3 is not available in ghcup for build-armv7-linux-deb10 and build-i386-linux-alpine at

https://gitlab.haskell.org/haskell/cabal/-/pipelines/54257

but GHC 8.10.7 is at

https://gitlab.haskell.org/haskell/cabal/-/pipelines/52918

? Why so? What do I need to tweak?

[hasufell]

@hasufell: do I read it right that GHC 9.2.3 is not available in ghcup for build-armv7-linux-deb10 and build-i386-linux-alpine at

https://gitlab.haskell.org/haskell/cabal/-/pipelines/54257

but GHC 8.10.7 is at

https://gitlab.haskell.org/haskell/cabal/-/pipelines/52918

? Why so? What do I need to tweak?

For armv7, there are simply no official bindists: https://downloads.haskell.org/~ghc/9.2.3/

For i386 alpine, I've been trying to get official bindists since over a year: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5213

Before, I built them manually. I won't do that anymore.

So both is up to GHC developers.

[Mikolaj]

@hasufell: thank you. In that case, I'm merging and backporting.

@bgamari: is there a chance for GHC 9.2.3 on armv7 and i386 alpine? If not, GHC 9.2.4?

[Mikolaj]

@Mergifyio backport 3.8

[mergify]

backport 3.8

✅ Backports have been created

• #8273 Build release archives (and validate) with GHC 9.2.3 (backport #8272) has been created for branch 3.8

[bgamari]

@hasufell: thank you. In that case, I'm merging and backporting.

@bgamari: is there a chance for GHC 9.2.3 on armv7 and i386 alpine? If not, GHC 9.2.4?

Indeed we can try for 9.2.4. However, I do recall running into toolchain trouble last time I attempted to build an ARMv7 release binary distribution.

I'm trying again to introduce i386/Alpine support in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6983.

[bgamari]

A quick update here:

• I am working on fixing ARMv7. Unfortunately, it is a bit tricky since it is remarkably hard to find a linker implementation for ARMv7 that isn't broken in one way or another. See https://gitlab.haskell.org/ghc/ghc/-/issues/21875
• I am not optimistic about i386/Alpine; I have fixed the first issue I ran into (our inability to resolve the _GLOBAL_OFFSET_TABLE_ symbol in the RTS linker). However, I quickly ran into a second issue: it appears that gcc produces relocations that the linker doesn't approve of when building a fully-static executable. I suspect this is because we are forced to compile with -fPIC to ensure that the produced objects are loadable at runtime. Sadly, it's not totally clear what to do about this. Tracking this issue in https://gitlab.haskell.org/ghc/ghc/-/issues/21876