jgm / pandoc

Universal markup converter
https://pandoc.org
Other
34.69k stars 3.39k forks source link

Can Binary Releases be Done for aarch64 and armv7h #5450

Closed stormdragon2976 closed 3 years ago

stormdragon2976 commented 5 years ago

Aarch64 and Armv7h machines are becoming more and more common place now days. There are Windows, Mac, and Linux binaries, but the Linux binaries do not cover these architectures. Please add binary releases for them.

jgm commented 5 years ago

stormdragon2976 notifications@github.com writes:

Aarch64 and Armv7h machines are becoming more and more common place now days. There are Windows, Mac, and Linux binaries, but the Linux binaries do not cover these architectures. Please add binary releases for them.

The latest ghc bindist I've found for arm architecture is ghc 7.10; debian has 7.8.x; and recent versions of pandoc require ghc >= 8.

I'm sure there's some way to do this. Hopefully someone who needs this can put in the time to figuring out how, and report back here. We could then consider making it part of the release process.

tarleb commented 5 years ago

AFAIK, both @vmchale and @2i3r managed to cross-compile pandoc. Maybe they have any insights on how we could support these platforms?

See also hslua/hslua#73.

2i3r commented 5 years ago

I have my armv7h cross-compiler setup running. unfortunately currently I don't have access to an aarch64 platform to test, but as far as I can say, armv7h binaries will run on most chips providing aarch64 such as armv8. (link and link). so it might be enough to provide only armv7h binary. I would love to share or help on this issue.

2i3r commented 5 years ago

On my tries direct compilation of pandoc and ghc, was so much slow. so I cross-compiled pandoc using cabal cross-compiler, which by itself needed binutils, libffi, ghc and pandoc dependecies cross-compiled, and then Simple build type in pandoc.cabal and disabling Template Haskell flag during compilation was needed. Someone may manage to run Template Haskell in cross-compile mode, so Simple build type may not be mandatory and data files would be embedded in the output binary.

mb21 commented 5 years ago

@2i3r do you think it would be hard to set this up on CircleCI (or similar), which we currently use for the pandoc Linux builds?

2i3r commented 5 years ago

I don't have any experience with CircleCI or similar tools. In the method I described above, what makes armv7h release is an special binary of cabal and ghc which configured to cross-compile binaries, and there are backend tools such as libraries, headers, utils and c compiler (multiple GBs) it uses. It can be configured inside a docker or a PC, then I think build tools such as CirckeCI might be set up to use those configured compilers and then if errors handled correctly then it might work as expected.

ickc commented 5 years ago

@2i3r, how much time such build would normally take? One concern to use CI to build is the time limit. In the past people has tried using QEMU in CI but it becomes too slow to be manageable.

Otherwise, especially when a docker can be set up, it should be easy to do it in CircleCI.

rhenwood-arm commented 5 years ago

I'm also interested in this activity. Drone.io have builders for AArch64 and ArmV7. If that is of interest, I could begin to work on this with a colleague.

jgm commented 5 years ago

@rhenwood-arm - since pandoc is open source, nothing stops you from building it and making the binaries available. I think that would be appreciated!

Whether we want to provide officially endorsed ARM binaries here (on the GitHub releases page) is another question. For now, I'd be happy to have a third-party source for them.

ickc commented 5 years ago

My experience on directly compiling on ARM:

For armv7l, I'm trying to provide it as an unofficial effort here: https://github.com/ickc/pandoc-arm/releases. Probably will fall in pandoc-extras later. (By the way, it took Raspberry Pi 4 about 2.8 GiB of RAM and 3 hours to compile.)

For aarch64, I have trouble getting stack/cabal compiled. If I'm not mistaken it is not supported.

If someone can give me the exact command of cross compiling pandoc targeting the 2 platforms, I can try to build them and test it on those arch.

In the long run, if it doesn't take too much time to compile with CI, and if there's a way to run tests on the target arch (current tests are run using cabal/stack in the compiling stage), then may be it can be provided as an official release.

By the way, am I right that for the current released binaries, the Windows' come from CI, but he macOS/Linux builds come from @jgm directly? I think this might be true in the past but not sure any more.

jgm commented 5 years ago

By the way, am I right that for the current released binaries, the Windows' come from CI, but he macOS/Linux builds come from @jgm directly? I think this might be true in the past but not sure any more.

Correct, but this may soon change. I've been working on getting releases built for all three architectures with GitHub Actions CI. See the rc/test branch.

vmchale commented 4 years ago

@stormdragon2976 if you want binaries, I have some here: https://github.com/vmchale/ghc-cross/releases/tag/Binaries

I also have linux -> linux cross-compilers for anyone who wants to try on their own: https://github.com/vmchale/ghc-cross/releases/tag/8.6.5 (both armv7 and aarch64)

stormdragon2976 commented 4 years ago

Howdy Peter,

Thanks for this, it is very awesome. Could you also provide armv7h binaries? I don't currently have an X86 to try the cross compiler.

One small problem that happened when I tried to convert a file:

Could not find data file /home/vanessa/.cabal/share/aarch64-linux-ghc-8.6.5/pandoc-2.7.3/data/abbreviations

Thanks, Storm

On Sat, Nov 30, 2019 at 08:48:57AM -0800, Peter hyman wrote:

@stormdragon2976 if you want binaries, I have some here: https://github.com/vmchale/ghc-cross/releases/tag/Binaries

I also have linux -> linux cross-compilers for anyone who wants to try on their own: https://github.com/vmchale/ghc-cross/releases/tag/8.6.5 (both armv7 and aarch64)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jgm/pandoc/issues/5450#issuecomment-559994325

-- ⛈🐲 Accessible low cost computers for everyone! Get your slice of the Pi: https://asliceofthepi.com My youtube channel: https://www.youtube.com/channel/UCdaTl5vl404OaRxAJPvb8Ew get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Follow me on GNU Social: https://social.wolfe.casa/storm "Have you ever been alone at night, thought you heard footsteps behind, and turned around and no one's there? And as you quicken up your pace you'll find it hard to look again because you're sure that someone's there." Iron Maiden - Fear of the Dark

jgm commented 4 years ago

One small problem that happened when I tried to convert a file:

Could not find data file /home/vanessa/.cabal/share/aarch64-linux-ghc-8.6.5/pandoc-2.7.3/data/abbreviations

Set the embed_data_files flag when you compile; this will ensure that the data files are included in the binary.

stormdragon2976 commented 4 years ago

Howdy Peter,

I just downloaded the aarch64 binary and tried it on the N2. That's when I got the error.

Thanks, Storm

On Sat, Nov 30, 2019 at 10:27:57AM -0800, Peter hyman wrote:

One small problem that happened when I tried to convert a file:

Could not find data file /home/vanessa/.cabal/share/aarch64-linux-ghc-8.6.5/pandoc-2.7.3/data/abbreviations

Set the embed_data_files flag when you compile; this will ensure that the data files are included in the binary.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jgm/pandoc/issues/5450#issuecomment-560009068

-- ⛈🐲 Accessible low cost computers for everyone! Get your slice of the Pi: https://asliceofthepi.com My youtube channel: https://www.youtube.com/channel/UCdaTl5vl404OaRxAJPvb8Ew get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Follow me on GNU Social: https://social.wolfe.casa/storm "I don't wanna face my fears! I'm afraid of 'em!" SpongeBob SquarePants

cstrouse commented 4 years ago

I work on Chromebrew and we'd like to have ARMv7 binaries as well since Google chose to ship all ARMv8 Chromebooks with 32-bit user ABIs due to only having 4GB of memory.

annProg commented 4 years ago

Any progress for this issue?

I try to build pandoc-2.9.2 for raspberry pi 4b, and got error

[133 of 161] Compiling Text.Pandoc.Readers.LaTeX
ghc: internal error: getMBlock: mmap: Invalid argument
    (GHC version 8.4.4 for arm_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
cabal: Leaving directory '/tmp/cabal-tmp-8306/pandoc-2.9.2'
ickc commented 4 years ago

I have exactly the same issue on both aarch64 and armv7l on Raspberry Pi 4 4GB model with pandoc 2.9+. 4GB was just enough to compile pandoc briefly after Raspberry Pi 4 launched but then pandoc's need soon exceeds that.

If you can't wait there's a build in https://github.com/ickc/pandoc-arm/releases, with the last version compiled successfully on RPi4, I think 2.8.

I should emphasize that you can always add more swap. Long time ago I think I successfully compiled pandoc with 1GB RAM (forgot if it was a RPi original or another low mem. laptop.) Just add a ton of swap and it will work, albeit very slowly and your swap device's life shortened if it is flash (e.g. microSD.)

I was about to experiment with zram if I have time and see if it helps.

(As other has noted, the proper way to do it is to cross-compile and do it in CI, and distribute it officially. But until that happens...)

annProg commented 4 years ago

@ickc the version is 2.7.3. It has problem on epub toc. So I am looking for 2.9+

ickc commented 4 years ago

Then build your own, add a ton of swap and wait for a few days.

annProg commented 4 years ago

I successfully compiled 2.9.2 . see https://github.com/arm4rpi/pandoc-arm/releases

ickc commented 4 years ago

How? Just ton of swap?

Are you going to provide that continuously in the future? If so there's no need for 2 of us doing the same thing. Also, if you decided to continually provided that, you may want to think about security implication. e.g. as outlined in my repo I found that it is reproducible build so providing checksum should be suffices (may be this is the reason we still need to have 2 independent builds just for others to double check.)

As said above if people working on cross compiling has a solution then that would be preferred as doing it in the cloud in the open means less trust on us is needed. But before that it may be something you and I can do in the interim.

annProg commented 4 years ago

@ickc I am trying to build using github actions. But got some errors, see https://github.com/arm4rpi/pandoc-arm/runs/483167534

failed to install.
base-compat-0.11.1-HgwyiOzKEQ9KmBXaEHlBfi failed during the configure step.
The exception was:
ExitFailure 1
base-orphans-0.8.2-3ZQM2pxPHbTALAIaG3rSz1 failed during the configure step.
The exception was:
ExitFailure 1
doctemplates-0.8.1-Iuw4He9PrsFAzb6E5YhZXp depends on doctemplates-0.8.1 which
failed to install.
ipynb-0.1-5azHA6CVSg970U03zfl88V depends on ipynb-0.1 which failed to install.
pandoc-2.9.2-5EHBhYTFz4u65WvZc3TiB5 depends on pandoc-2.9.2 which failed to
install.
pandoc-types-1.20-8EQHit822IcL8VC8fC6OZi depends on pandoc-types-1.20 which
failed to install.
skylighting-0.8.3.2-C2Li4Bm4LPW5TVFmKvF7GB depends on skylighting-0.8.3.2
which failed to install.
skylighting-core-0.8.3.2-BDFsVUriuS2BVnrNvKwqBs depends on
skylighting-core-0.8.3.2 which failed to install.
texmath-0.12.0.1-2htPgXHYu9jEzl2nKKanYP depends on texmath-0.12.0.1 which
failed to install.
time-compat-1.9.2.2-B4M2FpSJt3R4h2zQkxlzCq depends on time-compat-1.9.2.2
which failed to install.

##[error]Process completed with exit code 1.

do you know how to solve it?

ickc commented 4 years ago

Sorry no experience on GitHub Action.

What was the earlier errors? Do you see something fail to compile?

Could you bring me up to speed about the GitHub Action? e.g. do they provide armv7l and aarch64 or are you cross-compiling?

In the past experience when dealing with CI, is the "debug loop" can be troublesome. One way people often try to solve situation like this is to use the docker image of the CI instance itself (e.g. Travis CI) and debug it interactively.

annProg commented 4 years ago

Seem no armv7l and aarch64 provided, I am using qemu-user-static

for debug. run

docker run -it --privileged --rm ann17/pandoc-ghc-arm:latest /bin/bash
cd rootfs
cp /etc/resolv.conf etc
mount -t devtmpfs devtmpfs dev
mount -t devpts devpts dev/pts
mount -t sysfs sysfs sys
mount -t tmpfs tmpfs tmp
mount -t proc proc proc

# chroot to arm
chroot . /bin/bash
uname -m
cabal update
cabal install -v time-compat-1.9.2.2

docker image ann17/pandoc-ghc-arm:latest was build from https://github.com/arm4rpi/ghc-arm

annProg commented 4 years ago

Now I am trying to build for aarch64 and armv7l using Github Actions with qemu-user-static. Encountered two problems, can anyone help?

cabal resolving dependencies problem

Limited by execution time(6 hours), it is not possible to build successfull. So I want to pre build dependencies( see https://github.com/arm4rpi/pandoc-deps), but the problem is pandoc and pandoc-citeproc resolving deferent dependencies, libraries below need rebuild when build pandoc-citeproc, can not use prebuilt library for pandoc, the long suffix of library is different, for example: pandoc-2.9.2-cd37f71aada58e7c054fb0d9850c9c6facc99a5599ef764195fc2ac2b25bb988 and pandoc-2.9.2-028d873232afbbca4423e4e65d416bc237bf7809e93e4d4cd251f51fd681e9b8. So, now only pandoc will build successful.

In order, the following will be built:
 - time-compat-1.9.3 (lib) (requires download & build)
 - aeson-1.4.6.0 (lib) (requires download & build)
 - yaml-0.11.3.0 (lib) (requires download & build)
 - skylighting-core-0.8.3.2 (lib) (requires download & build)
 - pandoc-types-1.20 (lib) (requires download & build)
 - ipynb-0.1 (lib) (requires download & build)
 - doctemplates-0.8.1 (lib) (requires download & build)
 - aeson-pretty-0.8.8 (lib) (requires download & build)
 - HsYAML-aeson-0.2.0.0 (lib) (requires download & build)
 - skylighting-0.8.3.2 (lib) (requires download & build)
 - texmath-0.12.0.1 (lib) (requires download & build)
 - pandoc-2.9.2 (lib) (requires download & build)

armv7l always out of memory

I had add huge swap.

swapon: /mnt/swapfile: insecure permissions 0644, 0600 suggested.
swapon: /home/swapfile: insecure permissions 0666, 0600 suggested.
              total        used        free      shared  buff/cache   available
Mem:           6945         712         124          25        6108        5904
Swap:         30719          31       30688

alway out of memory when Compiling Text.Pandoc.Readers.LaTeX

[133 of 162] Compiling Text.Pandoc.Readers.LaTeX.Parsing
[134 of 162] Compiling Text.Pandoc.Readers.LaTeX
ghc: out of memory (requested 1048576 bytes)
CallStack (from HasCallStack):
  die', called at ./Distribution/Client/ProjectOrchestration.hs:977:55 in main:Distribution.Client.ProjectOrchestration
cabal: Failed to build pandoc-2.9.2 because it depends on pandoc-2.9.2 which
itself failed to build.
Failed to build
pandoc-2.9.2-a37414eb634713f674eb2c181278989d68c5c7af029fece038bbeefb7e04ca90.
The build process terminated with exit code 251
tarleb commented 4 years ago

I think the only solution for the out-of-memory error is to further break up Text.Pandoc.Readers.LaTeX into smaller modules.

Not sure about the dependency problems. The differences in hashes are probably due to different flags being used. Maybe try using more specific constraint --constraint='pandoc:embed_data_files instead of global --flag embed_data_files. You could also experiment with cabal.project.freeze files to ensure reproducible builds.

annProg commented 4 years ago

@tarleb thanks. I will try. only armv7l will out-of-memory. aarch64 does not have this problem

znmeb commented 4 years ago

I'm working on this via Docker on the NVIDIA Jetson Xavier AGX (arm64 plus CUDA and tensor cores). OS is Linux for Tegra (l4t), which is Ubuntu Bionic plus all the NVIDIA software. See http://github.com/znmeb/dockerfiles.

jgm commented 3 years ago

If anyone wants to try building on an ARM machine with a more recent ghc, ghcup now has experimental arm support: https://www.reddit.com/r/haskell/comments/lsz7ml/ann_ghcup0113_release_experimental_arm_support/

This doesn't help with memory issues, but note that we have broken up some of the bigger modules into smaller ones, which might help a bit, so those who had trouble before might find it worth while to try again.

znmeb commented 3 years ago

I can test this on a 4 GB Jetson Nano; the "traditional" method via cabal-install crashes when the Linux out-of-memory killer nukes some 'ghc' or 'llvm' processes.

But IMHO this isn't a technology problem, it's a resource problem - there aren't pre-built Pandoc ARM binaries because there's no readily-available low-cost CI/CD infrastructure for open source projects like Pandoc. I don't know if it would make economic sense for AWS or Microsoft / GitHub to start supplying such infrastructure, but I think we need to ask them for it.

jgm commented 3 years ago

If I recall, AWS offers ARM EC2 instances. Is that right? If so, that could be an option for building.

znmeb commented 3 years ago

Yeah - Gravitons. I did a couple of tests with Travis CI on Gravitions before they shut down their open source support. It didn't work; there was a 50-minute per step time limit and I couldn't break the build into small enough pieces.

jgm commented 3 years ago

Could we use it directly -- not through travis, but just spinning up an instance, doing the build, and uploading an artifact?

znmeb commented 3 years ago

Sure - you just need an account. But the 8 GB instances aren't cheap and it may never work in 4 GB if my Nano experience holds. Also, a lot of projects are suddenly biting this bullet because of the Apple Silicon Macs - they end up emulating x86_64 at drastically reduced speed. Engineering economics again :-(

My Docker context is at https://github.com/edgyR/edgyR-containers/tree/main/build-scripts/internal-pandoc. I'm still trying to get it to run on the Nano by updating GHC to something more recent than what ships on Ubuntu 18.04 but that's in a branch at the moment and it takes many hours to get to that point. I'll probably update to the full 8.6 Haskell platform and document the image as part of the project, since I have another use case for Haskell now.

ickc commented 3 years ago

I tried 8GB before and isn’t enough. I can try again soon.

znmeb commented 3 years ago

I tried 8GB before and isn’t enough. I can try again soon.

I'm using a 16 GB Jetson AGX Xavier with 8 cores and it does work there with 8 make jobs. I haven't tried with just 8 GB of RAM though. My script first rebuilds cabal-install, which will run in 4 GB.

The rewrite in progress first builds GHC 8.2, then cabal-install 3.0, then GHC 8.6, then cabal-install 3.4 and then Pandoc. As far as I know the only piece of this chain that won't run in 4 GB is the Pandoc step.

jgm commented 3 years ago

As of 7f1b933aaacf4a01fb23fa4989f190098e96e702 I've split apart the LaTeX reader, which should reduce its compilation footprint. It would be worth trying an armh build again with 8 GB and 4 GB. The LaTeX and Markdown writers are the other ones that take a lot of RAM to compile. See notes on #6546.

jgm commented 3 years ago

We have some money through donations which could pay for build time; the main issue is getting a process set up that makes it easy and painless for the developers to do the build.

znmeb commented 3 years ago

We have some money through donations which could pay for build time; the main issue is getting a process set up that makes it easy and painless for the developers to do the build.

Microsoft / GitHub / Azure is the logical place for that to happen. I'm sure open source ARM developers who are already on GitHub and who were kicked to the curb by Travis would be happy to beta-test it, and it would cement Microsoft's position in the open source world. :-)

jgm commented 3 years ago

Oh, I just thought of a simple solution. I can add a CPP macro lowmem (or something); when it is set, we can trigger OPTIONS_GHC pragmas in the three problematic source files that set -O0 just for those files. So you'd get a mostly optimized build, except for the three difficult modules. Testing that approach now on a 2 GB (non-arm) build machine. [EDIT: it worked.]

[Further edit: I did some benchmarks with the unoptimized LaTeX reader. The news is not good:]

    latex:             OK (1.46s)
      204 ms ±  17 ms, 417 MB allocated,  18 MB copied, 1230% slower than baseline

The markdown and latex writers are around 20% slower, not bad.

benz0li commented 3 years ago

I have successfully built pandoc for aarch64:

# uname -a; echo; pandoc -v; file /usr/bin/pandoc; ldd /usr/bin/pandoc; echo; pandoc-citeproc -V; file /usr/bin/pandoc-citeproc; ldd /usr/bin/pandoc-citeproc
Linux 4d1028ef6857 4.19.0-14-arm64 #1 SMP Debian 4.19.171-2 (2021-01-30) aarch64 GNU/Linux

pandoc 2.10
Compiled with pandoc-types 1.21, texmath 0.12.1.1, skylighting 0.8.5
Default user data directory: /root/.local/share/pandoc or /root/.pandoc
Copyright (C) 2006-2020 John MacFarlane
Web:  https://pandoc.org
This is free software; see the source for copying conditions.
There is no warranty, not even for merchantability or fitness
for a particular purpose.
/usr/bin/pandoc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
    not a dynamic executable

pandoc-citeproc 0.17.0.2
/usr/bin/pandoc-citeproc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
    not a dynamic executable

Someone please confirm, that everything works as expected. The Debian package is available at https://dl.b-data.ch/pandoc/releases/2.10/pandoc-2.10-1-arm64.deb.

@jgm I am happy to provide a multi-arch Docker Image (linux/amd64,linux/arm64) to replace utdemir/ghc-musl:v12-libgmp-ghc8101, which you are using to build the current version of pandoc.

P.S.: Sorry for not providing a more recent version of pandoc for testing. Bootstrapping GHC 8.10.1 is currently ongoing...

jgm commented 3 years ago

A multi-arch docker image would be great!

znmeb commented 3 years ago

I've built 2.11 with GHC 8.0 on aarch64 - I'm currently using 8.6 though.

benz0li commented 3 years ago

@jgm Here you go:

$ docker manifest inspect registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.1
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1379,
         "digest": "sha256:83cfc60cb1df984b14d6277946002de6bc7bec25c827f5f9de3b0c5d3aeaa571",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1379,
         "digest": "sha256:e54a66cf8ef7f8a60b93f6a51cae7a0bd853a763098ffb3dbda2bf91b7ab49ad",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      }
   ]
}

👉 Based on alpine:3.13 (musl libc), providing GHC 8.10.1 (integer-gmp) and cabal-install tool 3.2.0.0.

I have successfully built {pandoc-2.11.4-1-amd64.deb, pandoc-2.11.4-1-arm64.deb} with the above Docker image after applying the following patch:

diff --git a/Makefile b/Makefile
index f27272b08..bf866c65a 100644
--- a/Makefile
+++ b/Makefile
@@ -75,7 +75,7 @@ debpkg: man/pandoc.1
                    -v `pwd`/linux/artifacts:/artifacts \
           -e REVISION=$(REVISION) \
           -w /mnt \
-              utdemir/ghc-musl:v12-libgmp-ghc8101 bash \
+                   registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.1 bash \
           /mnt/linux/make_artifacts.sh

 man/pandoc.1: MANUAL.txt man/pandoc.1.before man/pandoc.1.after
diff --git a/linux/make_artifacts.sh b/linux/make_artifacts.sh
index 34c0bd082..f3aa4742d 100644
--- a/linux/make_artifacts.sh
+++ b/linux/make_artifacts.sh
@@ -2,6 +2,7 @@ set -e

 MACHINE=$(uname -m)
 case "$MACHINE" in
+  aarch64) ARCHITECTURE=arm64;;
   x86_64) ARCHITECTURE=amd64;;
   i686)   ARCHITECTURE=i386;;
   i386)   ARCHITECTURE=i386;;
@@ -68,5 +69,5 @@ mv pandoc $TARGET/bin
 strip $TARGET/bin/pandoc
 gzip -9 $TARGET/share/man/man1/pandoc.1

-tar cvzf $TARGET-linux-amd64.tar.gz $TARGET
+tar cvzf $TARGET-linux-$ARCHITECTURE.tar.gz $TARGET
 rm -r $TARGET

All credits go to @odidev who cross-compiled GHC 8.8.3 to aarch64-linux-musl* and @neosimsim for his docker-builder-images.
ℹ️ I merely put these two things together.

*unfortunately, it never made it into alpine > aports.

jgm commented 3 years ago

Thanks for this! I don't know much about Docker, sorry. Is there a way to audit this image, e.g., see the code by which it is produced?

benz0li commented 3 years ago

You find the code base for these images at https://gitlab.b-data.ch/ghc/ghc4pandoc, including CI/CD configuration at https://gitlab.b-data.ch/ghc/ghc4pandoc/-/blob/master/.gitlab-ci.yml.

Images for amd64 are built automatically by GitLab CI/CD (see https://gitlab.b-data.ch/ghc/ghc4pandoc/-/pipelines). The builds for arm64v8 images currently fail; getting stuck at step make binary-dist.
👉 I'm currently building and pushing arm64v8 images manually using the same Dockerfiles as for amd64 images. There seems to be an issue with the arm64 GitLab Runner image.


In the meantime, the following manifests have been added to the repositories' Container Registry:

jgm commented 3 years ago

Super! This worked well when I tried it locally. I'm going to try an arm build next on aws.

jgm commented 3 years ago
docker run -v `pwd`:/mnt \                                                      
                   -v `pwd`/linux/artifacts:/artifacts \                        
           -e REVISION=1 \                                                      
           -w /mnt \                                                            
           --memory=0 \                                                         
           --rm \                                                               
           registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4@sha256:e54a66cf8ef7f$
a60b93f6a51cae7a0bd853a763098ffb3dbda2bf91b7ab49ad \                            
           bash \                                                               
           /mnt/linux/make_artifacts.sh                                         
cabal-install version 3.2.0.0                                                   
compiled using version 3.2.1.0 of the Cabal library
The Glorious Glasgow Haskell Compilation System, version 8.10.1

So is it really ghc 8.10.1, not 8.10.4 as the name suggests? Is this expected?

benz0li commented 3 years ago

@jgm A digest points to a specific Docker image - ignoring the provided tag. sha256:e54a66cf8ef7f$ a60b93f6a51cae7a0bd853a763098ffb3dbda2bf91b7ab49ad is the image tagged with 8.10.1-linux-arm64v8 (GHC 8.10.1 for os/arch linux/arm64/v8).

If the script is supposed to use GHC 8.10.4 and work on both architectures, please use tag 8.10.4 only:

$ docker manifest inspect registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1379,
         "digest": "sha256:d42634183525b30082fc5b2edc5c236533e6cb1522e55417ea137a7749778ef3",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1379,
         "digest": "sha256:de85020ea67f7ec8ec531204bbd5b4619c1a5108220a6adccfca6afbd697961d",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      }
   ]
}

If it is supposed to work on aarch64 only, you may use registry.gitlab.b-data.ch/ghc/ghc4pandoc@sha256:de85020ea67f7ec8ec531204bbd5b4619c1a5108220a6adccfca6afbd697961d