ARM support

I just tried running ghcup to get started on my raspberry pi, but I got an error message:

Unknown architecture: armv7l

What's the status of ARM support? Is there something in particular blocking this?

It's true, there are armv7 bindists: https://downloads.haskell.org/~ghc/8.10.1/

But none for cabal: https://downloads.haskell.org/~cabal/cabal-install-3.2.0.0/

What needs to be done:

• bootstrap a cabal for armv7
• bootstrap a ghcup for armv7
• edit the download information json file and the bootstrap script

Ok, just opened https://github.com/haskell/cabal/issues/6715 on cabal!

added scopeplatforms statushelp-needed typeimprovement labels

@samuela can we create cabal bindists manually for the last few releases? It seems your PR will, at best, be merged after cabal 3.4 is released, according to phadej.

@maerwald Yeah, the main blocker AFAICT is Windows support. I don't have a Windows machine unfortunately but I think @bgamari on GitHub has volunteered to take that over.

I can take a look at manually creating bindists for ARM. I just kicked off the jobs for aarch64 and armv7. I think we should be able to simply pull the bindists out of the artifacts from those jobs. (Artifacts from the previous run just expired.) It'll be a pain to do this for past versions, but we can definitely start with bindists for the current one.

It'll be a pain to do this for past versions, but we can definitely start with bindists for the current one.

We need the exact versions. So what we could do is this: once we have a binary for "master", we write a job that simply does cabal install cabal-install-3.0.0.0 etc. and copy those artifacts over. We also need the plan.json files.

Hmm, ok I'm honestly not familiar with the Haskell/Cabal build systems at all, so I may not be the best person to do this. IUIC, you're saying we should use the current CI jobs eg for aarch64 to bootstrap a cabal binary. Then add new CI jobs to https://gitlab.haskell.org/samuela/cabal-build-test/-/blob/build-test/.gitlab-ci.yml to use that master binary to then build specific cabal versions, one CI job for each version, and each job outputting bindists as job artifacts. Is that correct? Where do the plan.json files come into play?

Then add new CI jobs to https://gitlab.haskell.org/samuela/cabal-build-test/-/blob/build-test/.gitlab-ci.yml to use that master binary to then build specific cabal versions, one CI job for each version, and each job outputting bindists as job artifacts. Is that correct?

Yes, all very simple.

Where do the plan.json files come into play?

They're somewhere in dist-newstyle/ folder and @hvr wants these to be added to the cabal tarballs that get shipped (so we know how to reproduce said tarball).

@maerwald Ok, so in terms of plan.json I found that --builddir=$(pwd)/dist is enough to capture a dist directory with plan.json found in dist/cache.

In terms of running this on past versions of cabal-install, hackage currently has the following versions published:

cabal-install-3.2.0.0, cabal-install-3.0.0.0,
cabal-install-2.4.1.0, cabal-install-2.4.0.0, cabal-install-2.2.0.0,
cabal-install-2.0.0.1, cabal-install-2.0.0.0, cabal-install-1.24.0.2,
cabal-install-1.24.0.1, cabal-install-1.24.0.0, cabal-install-1.22.9.0,
cabal-install-1.22.8.0, cabal-install-1.22.7.0, cabal-install-1.22.6.0,
cabal-install-1.22.5.0, cabal-install-1.22.4.0, cabal-install-1.22.3.0,
cabal-install-1.22.2.0, cabal-install-1.22.0.1, cabal-install-1.22.0.0,
cabal-install-1.20.2.0, cabal-install-1.20.1.0, cabal-install-1.20.0.6,
cabal-install-1.20.0.5, cabal-install-1.20.0.4, cabal-install-1.20.0.3,
cabal-install-1.20.0.2, cabal-install-1.20.0.1, cabal-install-1.20.0.0,
cabal-install-1.18.2.0, cabal-install-1.18.1.0, cabal-install-1.18.0.8,
cabal-install-1.18.0.7, cabal-install-1.18.0.6, cabal-install-1.18.0.5,
cabal-install-1.18.0.4, cabal-install-1.18.0.3, cabal-install-1.18.0.2,
cabal-install-1.18.0.1, cabal-install-1.18.0, cabal-install-1.16.1.0,
cabal-install-1.16.0.2, cabal-install-1.16.0.1, cabal-install-1.16.0,
cabal-install-0.14.1, cabal-install-0.14.0, cabal-install-0.10.2,
cabal-install-0.10.0, cabal-install-0.8.2, cabal-install-0.8.0,
cabal-install-0.6.4, cabal-install-0.6.2, cabal-install-0.6.0,
cabal-install-0.5.2, cabal-install-0.5.1, cabal-install-0.5.0,
cabal-install-0.4.0

So 3.0.2.0 and 3.0.1.0 are conspicuously absent, and versions before 3.x are ancient (full release history). Building 3.2.0.0 works without a hitch (that's currently what CI is doing). Building 3.0.0.0 does not work however:

ghc@1470d4eb689b:~$ cabal v2-install cabal-install-3.0.0.0 --installdir=$(pwd)/bin3.0.0.0 --builddir=$(pwd)/dist3.0.0.0 --install-method=copy --overwrite-policy=always --enable-split-sections
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] next goal: cabal-install (user goal)
[__0] rejecting: cabal-install-3.2.0.0 (constraint from user target requires
==3.0.0.0)
[__0] trying: cabal-install-3.0.0.0
[__1] next goal: base (dependency of cabal-install)
[__1] rejecting: base-4.13.0.0/installed-4.1... (conflict: cabal-install =>
base>=4.8 && <4.13)
[__1] rejecting: base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0,
base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
base-3.0.3.1 (constraint from non-upgradeable package requires installed
instance)
[__1] fail (backjumping, conflict set: base, cabal-install)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cabal-install, base

ghc@1470d4eb689b:~$

Yeah, you need base-4.12.0.0, which is provided by ghc-8.6.5. You can also check ghcup list, which now shows the base versions next to ghc versions and you can even do ghcup install base-4.12.0.0.

But I guess I haven't added ghc-8.6.5 yet, so it won't recognise that.

Right, and the registry.gitlab.haskell.org/ghc/ci-images docker images do not come with ghcup installed.

The GHC version is fixed here: https://gitlab.haskell.org/samuela/ci-images/-/blob/master/aarch64-linux-deb9/Dockerfile#L29. So building cabal-install 3.0.0.0 in CI requires either

• Changing the base upper bound <4.13 requirement in cabal-install 3.0.0.0
• Creating many more CI images, one for each architecture/GHC version combo

Would 3.2.0.0 be enough? How important is 3.0.0.0?

Would 3.2.0.0 be enough? How important is 3.0.0.0?

I don't really know. But users have recently requested to be able to install multiple cabal versions in parallel, due to certain incompatibilities. Maybe this is, for ARM, a tiny use case, but it would be nice.

I'm also seeing that not all GHC versions have arm versions: https://downloads.haskell.org/~ghc/8.6.5/ Somehow, we need a way to retroactively trigger such arm builds for older tags. Or someone does that manually. Since I'm still on mobile phone bandwidth, I cannot mess with VMs right now. But I guess another way would be to just do all that manually in a VM.

Hmm, yeah now we're getting into the release process for GHC haha... So how does the GHC release process work? Can we add CI jobs for ARM to the GHC builds?

I agree it would really be nice to have first-class support for ARM. Just a matter of what that will require.

I would say we should at least package ghc 8.10.1, 8.8.3, 8.6.5 and cabal-3.2.0.0 for arm. I don't really know how the GHC release process works.

mentioned in issue #25 (closed)

I don't have bandwidth to create ci-images for each of those combos, but if they come into existence I'd be happy to look into using them in the cabal CI.

This is also relevant !9 (merged)

I don't have bandwidth to create ci-images for each of those combos, but if they come into existence I'd be happy to look into using them in the cabal CI.

Well, I was hoping we can somehow just hijack this gitlab CI...

It would be fairly easy for GHC versions that have ARM builds (armv7 and aarch64) already. Unfortunately that rules out 8.6.5 and 8.8.3 though. They only have aarch64.

To be honest, I would probably rather we didn't offer ARM bindists for anything prior to 8.10. There are some very nasty bugs that were fixed in 8.10 and I think we should do everything we can to encourage users to upgrade.

That would definitely simplify things...

https://downloads.haskell.org/~ghc/8.2.2/ 8.2.2 has armv7, so we can bootstrap later GHCs with that.