Stack for Linux AArch64 (ARM64) #5709
Comments
|
Small update. I tried the stack aarch64 binary in release 2.7.1. It runs, but only as far as: |
|
Well it turns out: we can have nice things after all. After some poking around in the stack source, I was able to persuade it to build GHC from source using the binary from release 2.7.1. The resulting newborn stack was able to successfully run |
|
I'm not sure if this issue should be resolved with a doc fix (tell users which dependencies need to be present on the system in order to motivate stack to build GHC itself vs bailing out); or if the fix is to arrange for the appropriate pre-built binaries to be available for download. |
|
For posterity these are the dependencies I found were necessary on a stock Ubuntu 20 system: I found some of these from this thread: https://discourse.haskell.org/t/using-stack-on-raspberry-pi/2363/15 |
|
ghcup provides aarch64 stack binaries. |
Good to know! Note that as a clueless bystander a) I didn't know ghcup existed, and b) even if I did, its web page doesn't say it provides stack. Would it make sense to update one or more of the various doc pages to help folks looking for arm support? |
|
Are you sure it supports aarch64 stack binaries? The table on the landing page for GHCup has Stack crossed out for any aarch64 or armv7 platforms. |
|
Perhaps I should ask another question, again as a clueless outsider: if the binaries can be made (I made them myself), and the install code does a check for binaries being available, what would it take to get said binaries put in the place where it's looking for them? |
Yes, I am sure. The table is outdated: https://github.com/haskell/ghcup-metadata/blob/88696a0cc5ebb8fe5b15662f6a840be7c1cdd699/ghcup-0.0.7.yaml#L3071 |
|
The ARM64/AArch64 |
|
I don't think github actions currently provides M1 ARM64 machines for darwin, so this is probably a private runner. Whoever administers it, should probably be notified. |
|
@hasufell, thank you. I now understand the significance of |
|
I cleaned up old Docker images and set a cron job to prune them automatically, that should fix it. I'd be happy if someone else is interested in maintaining the build machines, in this case we have an Oracle Cloud ARM machine running. |
|
An alternative would be to maintain CI on GHC gitlab as well, which has runners for all platforms that GHC itself supports. I've done so in a branch here: https://gitlab.haskell.org/maerwald/stack/-/tree/717ec96c15520748f3fcee00f72504ddccaa30b5/.gitlab I've had some issues getting certain tests to pass there, but with a little bit of work, this could be done. Since the gitlab instance is getting a full-time devops soon, this would be low-maintenance. But YMMV. |
|
I don't care if someone else wants to maintain a CI on GitLab, but I have no desire to try to maintain that myself. |
Well, I wouldn't mind investing some more time in it. We're now building haskell-language-server on gitlab CI as well and let a github actions job pull the release artifacts. The question is rather if you're on board with that if it works well. |
|
I don't know what you're asking me. Anyone is free to run a CI system for Stack anywhere they want. It sounds like you're asking for some sign-off on some decision, but I don't know what that is. |
Whether stack upstream is interested to use GHC gitlab CI to create the official stack bindists. |
|
I'd prefer using the GitHub Actions if it's working, though we've always been open to contributions from elsewhere for bindists we don't support. If there are issues with the GitHub Actions in the future, I'm sure whoever's managing a release would be consider a GHC CI-generated executable. |
|
Circling back on this one: I think that the underlying problem is that since 2.7.1 there has been no binary built for aarch64 targets. Conversation above seems to suggest this was due to build machine hoarkage, which has since been resolved. Does that mean that whenever the next release (after the latest 2.7.5) is spun, it should have an aarm64 binary? Apologies, I'm somewhat familiar with GH actions, but not enough to know if there's a way to re-spin an old release for some targets that failed on the initial invocation. |
|
Hi, is there anything more that should be done to have arm64 binary for linux in next release? |
|
Hello, just wondering if this has been resolved? I am getting thanks |
|
@dewijones92, I don't know if this assists in the interim, but the If it does help, that would be good to know. |
|
@mpilgrem thanks but I can't find the stack exe in that tar you sent me |
|
@dewijones92 Thanks for the offer of help with making a release. On with size ~ 66 MB. Is that not the |
|
I'm not sure if this is relevant to the recent posts here, but I'm the OP and I wanted to clarify that this issue is about the failure of the "instructions most laypeople end up finding for installing a Haskell dev environment" on aarm64 machines. It's not that you can't find the binary somewhere, somehow (for example I was able eventually to build it myself). The problem is that supposedly folks don't need to build the binary, find it under a rock, or whatever. They're expecting to get everything installed by running one shell script. |
|
@dboreham |
|
@dboreham, for my part, that objective is fully understood. What would help me is to know that the GitHub workflow is, indeed, building something that will be of use to AArch64 users. |
|
Thank you for replying! My brain is down, atm, ( maintenance? : ) so I'll work at understanding this properly , later. However, Stack got installed when I used GHCup, There was a config.yaml.. here, I'll go look this up, so I'm not blathering idiocy at the whole world, ... There is nothing, dir or file, under /etc/, with "stack" as a substring. "$ stack path --stack-root This Aeson exception stuff began appearing after I cloned the "hindent" git repo, ( maybe I should just rip-out my entire linux-install, & begin clean, yet again? ) ~/.stack/config.yaml was a zero-byte file, Then there was another file in there, ...bash history had it: ~/.stack/global-project/stack.yaml ... I'll get back to this when I'm awake-enough to no-longer be dull-as-a-rock, Doh! I gave-up on trying Stack, So, I tried that, IF Haskell's base-4.17 is borked on all ARM CPU's, Again, not awake yet, brain is dull rock, 🙏 |
|
@libweirdness, we may to start from scratch. This is partly a 'voyage of discovery' for me too. You need three things to use Stack:
On 'system variant', hastinfo5 <- checkLib relFileLibtinfoSo5
hastinfo6 <- checkLib relFileLibtinfoSo6
hasncurses6 <- checkLib relFileLibncurseswSo6
hasgmp5 <- checkLib relFileLibgmpSo10
hasgmp4 <- checkLib relFileLibgmpSo3
let libComponents = concat
[ [["tinfo6"] | hastinfo6 && hasgmp5]
, [[] | hastinfo5 && hasgmp5]
, [["ncurses6"] | hasncurses6 && hasgmp5 ]
, [["gmp4"] | hasgmp4 ]
]From that code extract, I understand you can use (a) the 'standard' GHC variant ( In respect of obtaining a Stack executable for your operating system and architecture, again I do not know what GHCup can supply. However, I do know that the Stack GitHub workflow is currently likely building such executables and providing the binary Stack as an artifact. See my comment at #5709 (comment) and the discussion that led up to it. You may have a 'corrupt' The Stack executable can be put anywhere on your PATH. However, a good place to put it on Unix-like operating systems is In respect of Stack knowing where to find GHC, there are two alternative aspects of that: (1) Stack finding and obtaining GHC itself. At the moment, it can only find To tell Stack to use a version of GHC already on the PATH, you need to pass to Stack the Finally, I would add that if you have questions 'how do I get and use Stack?' you are more likely to get a quicker and fuller answer on the Haskell Community. Help is available here too, but the people who gather here are more interested in problems that are solved by changes to Stack's code base. |
|
ok, the "tinfo" problem is fixed ( yesterday, for me ), by a distro-package. I'll look up what that was... ncurses-libtinfo-devel GHCup installed a ghci, ghc, cabal, & stack, together, $ find /usr -name "libtinfo*" $ find /usr -name "libgmp*" OK, deleting my ~/.stack/ it created a ~/.stack/ dir, with exactly 1 file in it, config.yaml, that is zero bytes. It is Stack, itself, then, that is creating the broken config.yaml, on aarch64. giving you this, now, to keep you in the loop. I'll try understanding the rest of what's above, later. ( : |
|
Oh: ghc 8.10.7 and when I tried installing hindent with Stack ( which borked somethng, somehow, when I tried building the cloned git repo of hindent ) cabal install hindent got up until happy- cabal is version 3.6.2.0 I realized, finally, that aeson is borked, completely, cabal install aeson might fix that: it is now running, completing many builds, in the process... |
|
@libweirdness, that is frustrating. I am reaching the limits of what I can do to help - I think it will need somebody who has access to a AArch64 machine to take things forward. Clearly something is preventing Stack from writing a |
|
fwiw when I did some testing of this issue a while back I was able to use the lowest level ARM EC2 instance on AWS for a few hours, assuming the problem is reproducible on one of the Linuxen they provide. |
|
Hi, I managed to build a docker image with haskell stack, where the config is not an empty file like mentioned in this issue. Build ends up successfully and when running the image, the config file under ~/.stack/config.yml contains a minimal configuration: Also I installed packages mentioned before - without them, there was missing linux-aarch64-tinfo: Next I tried to build a helloworld project - builds and works fine and a custom one taken from github. |
|
I have (I hope) followed the instructions accurately and published a first release candidate for Stack 2.9.1, including bindists for Linux AArch64. See: https://discourse.haskell.org/t/ann-first-release-candidate-for-stack-2-9-1/5015. |
|
I have changed this issue's title to refer expressly to Linux AArch64 and I will open a separate issue for macOS AArch64. |
|
@mpilgrem many thanks for your efforts. But I can't get it working on my raspberry pi 4. Am I missing something? thanks 😄 |
|
@dewijones92, my understanding (as a Windows user) of the context to all this is as follows: In the past (and perhaps today) different Linux distributions had different C libraries to handle text-based user interfaces and you needed different 'variants' of GHC built against the different libraries to work on the different Linux distributions. It would be good to know what Linux distribution you have as your operating system (including version) on your Pi 4. I think Stack has added By the way, I assume you are using a snapshot that requires GHC 9.0.2 or GHC 9.2.4. The GHC download page for GHC 9.2.4 states:
Historically, Stack seems to have assumed that 'Debian 10' meant Can we try this experiment? If it works, it will assist with a permanent fix. Add the following stanza to your setup-info:
ghc:
linux-aarch64-tinfo6:
9.0.2:
url: "http://downloads.haskell.org/~ghc/9.0.2/ghc-9.0.2-aarch64-deb10-linux.tar.xz"
content-length: 164802160
sha1: 7dcaba567118c09bd486fb07b8dbaab66bb9a147
sha256: cb016344c70a872738a24af60bd15d3b18749087b9905c1b3f1b1549dc01f46d
9.2.4:
url: "https://downloads.haskell.org/~ghc/9.2.4/ghc-9.2.4-aarch64-deb10-linux.tar.xz"
content-length: 276846884
sha1: 31a21434ea3f9d5ee330299541ba048727296138
sha256: fc7dbc6bae36ea5ac30b7e9a263b7e5be3b45b0eb3e893ad0bc2c950a61f14ecThe explanation for what this is doing is here: https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info. The 'dictionary' above tells Stack to use the same version of GHC for OS key 'linux-aarch64-tinfo6' as it would use for OS key 'linux-aarch64'. |
|
I created a new stack project and it all works now on my raspberry pi 4 😄 Here is the repo link many thanks for your good work 😄 I also added the code from your proposed experiment and it also works 😄 |
|
Nice work @mpilgrem! |
|
@dewijones92, that's great. Stack asks itself 'What GHC do I need?' and, if it has not got it, it tries to fetch it. It uses a I also see, from I now understand that the Raspberry Pi has its own distribution of Linux - Raspberry Pi OS - based on Debian (currently Debian Bullseye) https://www.raspberrypi.com/documentation/computers/os.html. I will try to update Stack's online documentation. |
|
After some digging, I have now 2 setups, both running on ARM64. The first in which Stack fails (generates empty yaml files and aeson explodes) and the second in which everything works as expected. In both cases, GHC and friends were installed via GHCUP, running on a fresh install of Ubuntu 22.04 with all the updates applied and the same packages installed. In both scenarios GHC, GHCI, and Cabal work without a hitch. The difference between the two setups is that the first one (broken) runs over proot, while the second is running on a regular virtualized environment. Stack versions tested: 2.9.1 and 2.9.3. Thus, it stands to reason that something in stack (or something in one of its dependencies) does not like to be inside a proot env. Now that I have these two setups, any hints to what I could do next to chase this problem down? Other than the error itself, Stack does not seem to generate detailed logs of what could be happening. |
|
@francesquini, can you post the error itself (from Stack 2.9.3) to get a better understanding of what you are experiencing? |
|
Sure, sorry for not posting it earlier. Immediatelly after install, I can't create a project since the global config is empty: Note the 0-sized file. No problem, I can configure it myself: Unfortunately, that' s not enough: Note that not only the |
|
@francesquini, that is very odd. The part of Stack's code that writes the files extracted from a -- | Write files to the new project directory.
writeTemplateFiles ::
MonadIO m
=> Map (Path Abs File) LB.ByteString -> m ()
writeTemplateFiles files =
liftIO $
forM_
(M.toList files)
(\(fp,bytes) ->
do ensureDir (parent fp)
writeBinaryFileAtomic fp $ lazyByteString bytes)
|
|
As GHC and Cabal work on your PRoot system, perhaps you could write a small piece of test code to see if |
|
@mpilgrem That's interesting.... The documentation for
The "durability", is somewhat explained in the documentation for
Well, I can attest I'm not having an "abrupt power loss" :), but something is making the written bytes to be lost. I'll try to change the current call to |
|
@mpilgrem Indeed the problem was with RIO, in particular, with the I executed the following code on my machine: {-# LANGUAGE NoImplicitPrelude #-}
module Main (main) where
import RIO
import RIO.File
import RIO.ByteString
main :: IO ()
main = do
writeBinaryFile "writeBinaryFile.txt" bs
writeBinaryFileAtomic "writeBinaryFileAtomic.txt" bs
writeBinaryFileDurable "writeBinaryFileDurable.txt" bs
writeBinaryFileDurableAtomic "writeBinaryFileDurableAtomic.txt" bs
where
bs = pack [65 .. 75]On the 'PRoot' system, I got: On the other ARM64 machine, all files have 11 bytes each, as expected. Fortunately, Stack source code concentrates all calls to Lines 293 to 296 in 503ef24 After modifying line 296 to: or to I'll open an issue for the maintainers of RIO, however, for stack itself some questions remain. Is the use of atomic really necessary? Wouldn't durable (or even the regular version) be enough? |
|
Issue regarding the unexpected behavior above: fpco/unliftio#107 |
|
I am going to close this 'general' issue, having separated out @francesquini's PRoot-related problem. |
Apologies, I see from the history that this has come up again and again. I'd like to understand the state of Stack for ARM64. I'm attempting to use Ubuntu rather than macos.
When I follow the batteries included instructions I get this:
But I can see from various issues and posts that there is a GHC for ARM64, and there's even a CI job for Stack on ARM64: https://github.com/commercialhaskell/stack/actions/workflows/arm64-release.yml and also binary packages shipped in this release : https://github.com/commercialhaskell/stack/releases/tag/v2.7.1 (although internet lore claims they don't work).
I suppose I'm wondering what's the gap between the things that exist and
get.haskellstack.orgworking above? Is there a mailing list, forum or somewhere that I can read to catch up? Also if I can help or contribute to make this happen I'm happy to do that. Thanks, hope this makes sense.The text was updated successfully, but these errors were encountered: