Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Official ARM support #2103

Open
blitzcode opened this issue May 5, 2016 · 135 comments
Open

Feature Request: Official ARM support #2103

blitzcode opened this issue May 5, 2016 · 135 comments

Comments

@blitzcode
Copy link

@blitzcode blitzcode commented May 5, 2016

The current process of getting a Stack Haskell application build on ARM is rather... tricky:

https://github.com/blitzcode/hue-dashboard/#raspberry-pi

I'd love for Stack to have an official ARM bindist and be able to install GHC/LLVM with stack setup.

@borsboom
Copy link
Contributor

@borsboom borsboom commented May 5, 2016

The main thing we'd need to start to start generating ARM binaries for releases is a Vagrantfile that sets up a build environment similar to the ones found in https://github.com/commercialhaskell/stack/tree/master/etc/vagrant. I guess that Vagrantfile would have to launch a VM on an Arm-supporting VPS provider (or in an emulator, but that might be really slow).

From your link, it sounds like we may also want to add support for installing LLVM to stack setup. Although I guess if you already have LLVM, stack setup might already be able to take care of installing GHC (at least once we add a link to the correct GHC bindist for ARM to https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml).

@borsboom borsboom added this to the P3: Optional milestone May 5, 2016
@blitzcode
Copy link
Author

@blitzcode blitzcode commented May 6, 2016

I initially tried building on QEMU, but had little success with it. The Raspberry Pi with its 1GB of RAM might be problematic for reliable builds. As you suggest, a VPS provider that offers server-grade ARM systems with enough memory seems like the best option.

I filed a issue #1742 a while ago to suggest stack should install LLVM as it's often difficult to pick the right version and different GHC versions need different LLVMs. Wasn't there talk of GHC8 bundling the right LLVM anyway?

@quyse
Copy link
Contributor

@quyse quyse commented May 8, 2016

@blitzcode Just a few notes, I have set up an ARM machine on Scaleway few months ago for CI purposes, and it's doing great. I would advise to use Arch Linux distribution instead of Debian/Ubuntu, as it has up-to-date binary packages, in particular GHC 7.10.3 (on ARM too) and LLVM, which work together flawlessly. As I remember the setup was relatively straightforward, just install ghc, llvm35, cabal-install from packages, add some swap space (2Gb RAM will not be enough), compile stack from sources, and that's it. Don't do parallel builds, as it will run out of memory. Unfortunately I don't know other good ARM cloud providers, I would love to hear about any providing bigger ARM machines in terms of memory.

@blitzcode
Copy link
Author

@blitzcode blitzcode commented May 9, 2016

@quyse Yes, I was checking them out, seems really affordable. 2GB really wasn't enough? I got everything to build with the 1GB RPi and 100MB swap, I figure 2GB should be smooth sailing. Maybe only with -j1 / -j2, though. I'm a bit wary of Arch simply because I don't like the idea of being forced to upgrade and I want reproduceability. If 1 year from now the SD card in a RPi I deployed dies, I'd want to be able to set up the exact same system again. If Arch has already moved to GHC8 by then, I might be in trouble with my LTS 5.x code. At least that's my worry without ever having tried Arch. It seems otherwise much easier to get going than Debian Jessie with its dated packages...

@quyse
Copy link
Contributor

@quyse quyse commented May 9, 2016

@blitzcode I've checked again what I'm doing there, actually I'm not specifying -j1, so I guess it's actually -j4 by default (because of 4 cores), no wonder it was running out of memory :) With additional swap space it's fine though. -j1 is just too slow.
Good point about Arch, yes, you are usually forced to upgrade. You can freeze your system's state by simply not upgrading, you also can make a backup of your pacman cache, so you can restore packages in the future without contacting distribution servers. But, yes, probably easier to stick with Debian in your case. I'm just not worrying too much about reproduceability at the moment, as I'm upgrading regularly to the latest LTS.

@borsboom
Copy link
Contributor

@borsboom borsboom commented May 20, 2016

I'm trying to build a stack binary on a Scaleway VM running Debian Jessie (to match the GHC bindist), but am having trouble with LLVM. I downloaded an LLVM bindist as recommended in here, but when I try to use it I get:

# opt --version
Illegal instruction

Any ideas where I can easily get an LLVM that will work?

@blitzcode
Copy link
Author

@blitzcode blitzcode commented May 21, 2016

@borsboom That's puzzling, last time I checked their servers were armv7 / 32 bit, same as the Raspberry Pi with Raspbian. So it's really strange that the LLVM bindist would not work.

Could you maybe do a lscpu, uname -a and maybe run file or whatever on the LLVM bindist and see if the architectures etc. match? I also sometimes hear that SoC vendors have a lot of discretion on what to include in their ARM cores, like NEON, 32/64 bit, etc, so maybe there's something different about the server-grade SoCs Scaleway uses. No idea.

@borsboom
Copy link
Contributor

@borsboom borsboom commented May 21, 2016

@blitzcode:

root@scw-476b18:~# uname -a
Linux scw-476b18 4.3.5-std-1 #1 SMP Fri Feb 19 11:52:18 UTC 2016 armv7l GNU/Linux

root@scw-476b18:~# lscpu
Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
Model name:            ARMv7 Processor rev 2 (v7l)
CPU max MHz:           1333.0000
CPU min MHz:           666.5000

root@scw-476b18:~# /usr/local/bin/opt --version
Illegal instruction

root@scw-476b18:~# file /usr/local/bin/opt
/usr/local/bin/opt: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=f99b13805d70643bc8a3485026fb7ab9f6a37f04, stripped

Oddly enough, the file output matches that for ghc (which does run):

root@scw-476b18:~# /opt/ghc-7.10.3/lib/ghc-7.10.3/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

root@scw-476b18:~# file /opt/ghc-7.10.3/lib/ghc-7.10.3/bin/ghc
/root/opt/ghc-7.10.3/lib/ghc-7.10.3/bin/ghc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=c2002709f062e00b92536c9c6770e7fa9d96f7d8, not stripped
@varosi
Copy link

@varosi varosi commented Jun 9, 2016

@borsboom, you need at least LLVM 3.5.2 or greater. There is a fix related to GHC in it.

@varosi
Copy link

@varosi varosi commented Jun 9, 2016

@blitzcode, I'm running GHC 7.10.2 with LLVM 3.5.2 on ARMv7 (32bit) and it is working well.

@blitzcode
Copy link
Author

@blitzcode blitzcode commented Jun 9, 2016

@borsboom I'm terribly sorry, I said 3.5.2 in my document and then linked 3.5.1, dammit...

@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Jun 9, 2016

Note that another thing that will likely need to be resolved is support for byte alignment in store - mgsloan/store#37 - as ARM cares about this.

@varosi
Copy link

@varosi varosi commented Jun 9, 2016

@varosi
Copy link

@varosi varosi commented Jun 9, 2016

This temporarily workarounds this problem:

cabal install --dependencies-only --constraint=cryptonite==0.15

@andreyk0
Copy link

@andreyk0 andreyk0 commented Jun 10, 2016

Jumping here from #1332

I've finally taken some time to untangle haskell/arm stuff from my personal files, here's the result:
https://github.com/andreyk0/haskell-on-arm

Hope it helps somebody.

@varosi cryptonite used to be an issue for me at some point but haven't had any problems recently. Something got fixed, I imagine.

@varosi
Copy link

@varosi varosi commented Jun 11, 2016

@andreyk0, fix is not yet pushed in Hackage and I still have this problem on my ARM.

@andreyk0
Copy link

@andreyk0 andreyk0 commented Jun 11, 2016

@varosi hmm, could be my environment then. I don't remember everything but (it's in the readme in that repo and my images are on dockerhub) I've installed LLVM from the project's downloads page and hacked 7.10.2 to be a symlink to 7.10.3, so there's no 7.10.2 in my system.

@varosi
Copy link

@varosi varosi commented Jun 13, 2016

with cryptonite-0.15 it is working fine on IMX.53 board. So I'm building project successfully with Stack. It'll be great if Stack have official distro for ARM and support stack setup.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jun 15, 2016

I did some more experimenting with this. I got Debian Jessie for armhf running in qemu (note: the LLVM bindists are not compatible with armel or with Wheezy for armhf which I tried first) and things seem to be working, but very slow. I'm building cabal-install and it's been running for about 10 hours now, and looks like it might be finished in the next hour or so. At that rate, Stack will take at least a couple of days to build, and I expect the integration tests to take another day or so to run. At that point I'll at least know whether Stack works properly on ARMv7.

The situation with LLVM bindists is annoying though; they only seem to support fairly specific versions of distros (unlike GHC bindists, which tend to work on a wide range). And since each GHC version needs a specific version of LLVM, we can't leave it up to the Linux distro to install LLVM for us. So we could officially support ARMv7 on Jessie armhf, but not necessarily on any other distributions or versions.

@blitzcode
Copy link
Author

@blitzcode blitzcode commented Jun 15, 2016

@borsboom Good to hear, but I'm surprised that the build times are so much worse than on the RPi. I've read several times about good results with QEMU. Hope you build Cabal with EXTRA_CONFIGURE_OPTS="" ./bootstrap.sh, it helps quite a bit!

In the meantime, Stack v1.1 has been working absolutely without issues for me on ARM after the initial setup pains.

Debian Wheezy only seems to have LLVM 3.1 available, Wheezy only goes to 3.5, had to download the LLVM binaries. Where on the LLVM page does it actually say with which distros the binaries have been tested?

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jun 15, 2016

Thanks for the tip about EXTRA_CONFIGURE_OPTS; I didn't know that!

I didn't see anywhere on the LLVM page where it mentioned the distros. But when I tried clang+llvm-3.7.1-armv7a-linux-gnueabihf (I'm using GHC 8.0.1, so the newer LLVM is required) on Wheezy, this happened:

manny@debarm:~$ clang
clang: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by clang)
clang: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by clang)
@blitzcode
Copy link
Author

@blitzcode blitzcode commented Jun 15, 2016

Oh, it's gated by glibc, that makes sense. That's an unfortunate problem...

Once you have Cabal be sure to use --disable-library-stripping --disable-executable-stripping and / or set executable-stripping: False + library-stripping: False in Cabal's ~/.cabal/config. I had to start over and rebuild all of Stack's dependencies on my first try :/

@varosi
Copy link

@varosi varosi commented Jun 15, 2016

I have tested latest cryptonite-0.17 on ARMv7 and the compilation issue from 0.16 is fixed (haskell-crypto/cryptonite#90) there. So Stack will be building alright now.

@andreyk0
Copy link

@andreyk0 andreyk0 commented Jun 15, 2016

@varosi yeah, I must've hacked flags long time ago and forgot about it, sorry for the noise, you were right. Had the same problem with a clean ghc8.0.1 build, luckily it's fixed now!

@andreyk0
Copy link

@andreyk0 andreyk0 commented Jun 15, 2016

@borsboom " ARMv7 on Jessie armhf" is probably the way to go, too much pain to get this stuff to work anywhere else for now.
Regarding QEMU build times: I only used cabal-install once, about a year ago to build stack itself. Since then using stack to build packages and newer versions of stack itself. Most packages and my tiny projects compile in a few minutes, which is reasonable. There are outliers though, e.g. compiling regex-tdfa the other day with ghc8.0.1 took over 2h. Don't know why. At least stack will reuse the binaries, which helps a lot.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jun 15, 2016

Replying to myself here, regarding #2103 (comment): I've seen some issues in other projects that need ARM CPUs with NEON support and have the same Illegal Instruction error on Scaleway (where the CPU doesn't have NEON support), so I'm guessing that's what is going on with the LLVM bindist. Annoying, because this would be much faster/easier if I could build on Scaleway.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jan 14, 2019

Awesome, can you make a PR with this update to stack-setup-2.yaml? I've copied the bindist to https://github.com/commercialhaskell/ghc/releases/download/ghc-8.6.3-release/ghc-8.6.3-armv7-deb8-linux.tar.xz, so you can change the URL to that so we don't spend your S3 money.

@dustin
Copy link

@dustin dustin commented Feb 5, 2019

I've been trying to work with aarch64 as well and ran into a different problem.

I successfully built a project from lts-13.5 using 8.6.2 with --skip-ghc-check. I've also built ghc-8.6.3 for aarch64 and am trying to use it. I'm a bit confused as to how the pieces fit together, though:

I updated stack-setup-2.yaml to reference my 8.6.3 build for linux-aarch64, but it doesn't seem to find it:

I don't know how to install GHC for (Linux,AArch64), please install manually

How do I tell what it's looking for and convince it that it can use it?

@varosi
Copy link

@varosi varosi commented Feb 5, 2019

@dustin
Copy link

@dustin dustin commented Feb 5, 2019

--system-ghc works OK. I'm trying to figure out how to create a build environment that will correctly use the GHC I'm defining in stack-setup-2.yaml

i.e.:

    linux-aarch64:
        [...]
        8.6.3:
            url: "https://s3.amazonaws.com/public.west.spy.net/ghc/ghc-8.6.3-aarch64-unknown-linux.tar.xz"
            content-length: 175784516
            sha1: a57a0356f8ece8ddcb4abb9b492b53e4b858fbad
            sha256: 08a441d8bfa9cf273451e6946f3ef02cbb0314bbf364beb4ed0f645d488eb473

@borsboom
Copy link
Contributor

@borsboom borsboom commented Feb 6, 2019

@dustin I think you've found a Stack bug, in this line:

Platform (OtherArch "aarch64") Cabal.Linux   -> return "linux-aarch64"

When that was written, Cabal didn't have a specific enum value for aarch64, so it checks again OtherArch. But since then, looks like Cabal has added a value which means OtherArch is no longer being matched.

I've just pushed a change to the stable branch to fix this. You can upgrade to it using

stack upgrade --git --git-branch stable
@dustin
Copy link

@dustin dustin commented Feb 6, 2019

Didn't quite make it... I had to fight a little to get it to try (system ghc, allow newer, etc...). It failed after a while, though:

Progress 58/175

--  While building package stm-2.4.5.0 using:
      /root/.stack/setup-exe-cache/aarch64-linux/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.2 --builddir=.stack-work/dist/aarch64-linux/Cabal-2.4.0.1 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: /tmp/stack-upgrade889/stack/.stack-work/logs/stm-2.4.5.0.log

    Configuring stm-2.4.5.0...
    Preprocessing library for stm-2.4.5.0..
    Building library for stm-2.4.5.0..
    [ 1 of 10] Compiling Control.Concurrent.STM.TBQueue ( Control/Concurrent/STM/TBQueue.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Concurrent/STM/TBQueue.o )
    [ 2 of 10] Compiling Control.Concurrent.STM.TChan ( Control/Concurrent/STM/TChan.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Concurrent/STM/TChan.o )
    [ 3 of 10] Compiling Control.Concurrent.STM.TMVar ( Control/Concurrent/STM/TMVar.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Concurrent/STM/TMVar.o )
    [ 4 of 10] Compiling Control.Concurrent.STM.TQueue ( Control/Concurrent/STM/TQueue.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Concurrent/STM/TQueue.o )
    [ 5 of 10] Compiling Control.Concurrent.STM.TVar ( Control/Concurrent/STM/TVar.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Concurrent/STM/TVar.o )
    [ 6 of 10] Compiling Control.Concurrent.STM.TArray ( Control/Concurrent/STM/TArray.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Concurrent/STM/TArray.o )
    [ 7 of 10] Compiling Control.Monad.STM ( Control/Monad/STM.hs, .stack-work/dist/aarch64-linux/Cabal-2.4.0.1/build/Control/Monad/STM.o )

    /tmp/stack889/stm-2.4.5.0/Control/Monad/STM.hs:34:9: error: Not in scope: `always'
       |
    34 |         always,
       |         ^^^^^^

    /tmp/stack889/stm-2.4.5.0/Control/Monad/STM.hs:35:9: error: Not in scope: `alwaysSucceeds'
       |
    35 |         alwaysSucceeds,
       |         ^^^^^^^^^^^^^^
@tolysz
Copy link
Collaborator

@tolysz tolysz commented Mar 4, 2019

@dustin I am building directly on Nvidia Xavier Ubuntu 18.04.

lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):           4
Vendor ID:           Nvidia
Model:               0
Model name:          ARMv8 Processor rev 0 (v8l)
Stepping:            0x0
CPU max MHz:         2265.6001
CPU min MHz:         115.2000
BogoMIPS:            62.50
L1d cache:           64K
L1i cache:           128K
L2 cache:            2048K
L3 cache:            4096K
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp

This is a bit pain, it comes with ghc-8.0.1, I build 8.2.2, than 8.6.3 from it.
installed stack-1.6.6-be415545029d1bcafddb9fc13b8283e3d1b1abb1-linux-aarch64.gz
then:

./stack setup --resolver=lts-11.22 --stack-yaml ~/.stack/global-project/stack.yaml
./stack setup --resolver=lts-13.9 --stack-yaml ~/.stack/global-project/stack.yaml

where stack.yaml

setup-info:
   ghc:
      linux-aarch64-nopie:
            8.2.2:
              url: "https://ssh.cdn-kio.sx/ghc-8.2.2-aarch64-unknown-linux.tar.xz"
              content-length: 152979556
              sha1: 93320f0e2987c03e395369f2d6f54276c08e8e86
            8.6.3:
              url: "https://ssh.cdn-kio.sx/ghc-8.6.3-aarch64-unknown-linux.tar.xz"
              content-length: 191169108
              sha1: aca53485908607126a35fdf9a513fe2f5554b6cd

then manual git clone and stack install
worked.

@fuszenecker
Copy link

@fuszenecker fuszenecker commented Nov 8, 2019

Thanks for the excellent job you did for stack.
I think, both arm-v7 and aarch64 would be great.

@Fleuv
Copy link

@Fleuv Fleuv commented Feb 24, 2020

Seems like I'm the only one thus far who managed to get:

# stack setup
Unable to find installation URLs for OS key: linux-aarch64-tinfo6

I'm trying to run stack on an ARM machine from Scaleway, here some specs:

# uname -a
Linux my-scw-machine 4.19.0-8-arm64 #1 SMP Debian 4.19.98-1 (2020-01-26) aarch64 GNU/Linux
# lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           Cavium
Model:               1
Model name:          ThunderX 88XX
Stepping:            0x1
BogoMIPS:            200.00
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
# stack --version
Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) aarch64 hpack-0.31.2
@varosi
Copy link

@varosi varosi commented Apr 7, 2020

Is there a 2.3 RC binary for ARMv7 to test it?

@fuszenecker
Copy link

@fuszenecker fuszenecker commented May 2, 2020

"We have reduced the number of platforms that we support with binary releases." -- unfortunately, this includes ARM :(

@varosi-chaosgroup
Copy link

@varosi-chaosgroup varosi-chaosgroup commented May 4, 2020

Okay, thanks for the info!

@vaclavsvejcar
Copy link

@vaclavsvejcar vaclavsvejcar commented May 7, 2020

Is dropping official ARM support good move regarding the fact that Apple will likely migrate from Intel to ARM processors for their computers in following years?

@varosi
Copy link

@varosi varosi commented May 7, 2020

There is also a great ARM penetration into server's market. IoT market is already occupied by ARM processors.

@varosi-chaosgroup
Copy link

@varosi-chaosgroup varosi-chaosgroup commented May 19, 2020

For small and slow machines like Raspberry Pi, it would be great if there is a binary distribution.

@fosskers
Copy link
Contributor

@fosskers fosskers commented May 19, 2020

@nh2 would your static compilation Nix magic make this more possible?

@vielmetti
Copy link

@vielmetti vielmetti commented May 21, 2020

On arm64, I'm trying to build Cilium. Cilium depends on Istio and Envoy, and several of those packages use hadolint to lint their Dockerfiles. Building hadolint depends on stack. & that brings me here.

From what I can see, the CI for stack is Azure Pipelines, and there is an external agent support for Azure recently that can support arm64. See microsoft/azure-pipelines-agent#1911 for that issue.

@ryandesign
Copy link

@ryandesign ryandesign commented Aug 3, 2020

Apple will likely migrate from Intel to ARM processors for their computers in following years?

With the first models scheduled to appear before the end of this year, in fact. So hopefully someone is working rapidly toward getting ghc and stack ready for that.

@varosi
Copy link

@varosi varosi commented Aug 3, 2020

If Stack developers need someone to test Stack on such a machine - I'll test it.

@borsboom @fuszenecker

@fosskers
Copy link
Contributor

@fosskers fosskers commented Aug 3, 2020

Yes please.

@jmatsushita
Copy link

@jmatsushita jmatsushita commented Aug 3, 2020

@Fleuv I got the same error message you did using Debian Buster which uses tinfo6. I could circumvent the issue by using an ubuntu:18.04 base image which allowed stack to find an aarch64 GHC bindist (since this version of ubuntu seems to use tinfo5). I could probably have used Debian 9 instead, since that's the bindist that stack used anyway.

@tolysz
Copy link
Collaborator

@tolysz tolysz commented Oct 7, 2020

Hi Guys,

I am trying to bootstrap some later stack on aarm64 starting with stack-1.6.6-be415545029d1bcafddb9fc13b8283e3d1b1abb1-linux-aarch64.gz (I moved the urls to http://ghcjs.tolysz.org/ backed by s3).
Then I can build stack-1.9.3.1 (you need to fix aarm64 support first, by adding extra line to setup... otherwise it you will not be able to use any of the compilers after you build it).

I build my own ghc's(how to build it from git) but you should be able to grab some of the official ones, you might need to install some additional llvm compilers it will complain with opt check which version does it need.

It is not this hard to set it on your own, just the bootstrapping is tedious...
Basically you check which ghcyou need for each lts then you build them from sources starting low enough so the native ghc works. Then you extend setup-info.yaml with that compiler, then use stack to stack exec -- build-ghc... sometimes you need to stack exec env and manually setup env vars...

Basically for Nvidia Jetson(Xaviers, nano) 8.0.2(ubuntu18:04) -> 8.2.2 -> 8.6.3; 8.2.2 -> 8.6.5 (need to play with env)
then stack-1.6.6 -> stack-1.9.3.1(patch) -> stack-2.5.0.1

I am not sure how portable all those binaries are... but it should be safe to run them on some scratch servers.
For ghc-8.6.5 you might need libgmp-dev llvm-6.0
PATH=/usr/lib/llvm-6.0/bin/:$PATH stack install happy

UPDATE:
start with the latest link, put it on your path(unpack, rename)...
stack --resolver nightly-2020-10-07 setup
will do the job... if you are lucky(and have libtinfo.so.6)... the people behind stack made some magic... otherwise build your own ghc's (or use the ones I did) (once It builds beyond 8.6.5 I will let you know... it just takes a while to compile)
Just create stack.yaml and you can install custom ghc via:
stack setup --resolver=lts-11.22 --stack-yaml ~/.stack/global-project/stack.yaml

UPDATE2:
Looks like there is a nice task to add nopie libtinfo etc... classification for arm64...

@robwithhair
Copy link

@robwithhair robwithhair commented Jan 14, 2021

Hi there. I’m struggling to build my project on ARM64 on raspberry pi 4 in 64bit. We were hoping to migrate to ARM64 on AWS too for some of our data processing tasks. Are there plans to add ARM64 support back into Stack at all?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet