Trying to emerge dev-lang/ghc on arm64 without much luck

[jgaz]

I'm trying to emerge dev-lang/ghc on my Raspberry Pi 5 so that I build app-office/hledger in the Gentoo Haskell tree on Github. It's basically a better version of app-office/ledger. For those not familiar, see https://plaintextaccounting.org/.

Anyway, attempts to build it without the LLVM flag fail:

Code: Select all

# emerge --ask dev-lang/ghc
[ebuild  N    ] dev-lang/ghc-9.2.8 
[ebuild  N    ] app-admin/haskell-updater-1.4.1.0 

Fails with:

Code: Select all

 * ERROR: dev-lang/ghc-9.2.8::haskell failed (setup phase):
 *   No binary available for 'arm64' arch yet, USE=ghcbootstrap

Attempts to build it with ghcbootstrap enabled fail:

Code: Select all

 * ghc not found
 * ERROR: dev-lang/ghc-9.2.8::haskell failed (pretend phase):

Taking a look at the ghc-9.2.8.ebuild in portage, I see:

Code: Select all

LLVM_MAX_SLOT="14"

The oldest version of LLVM in portage appears to be 15.0.7.

What I've learned so far:

• The ghcbootstrap keyword isn't an option to build GHC from a C compiler as one might expect.
• If I understand correctly, with the llvm flag enabled GHC should build but it requires a version of LLVM <=14 in order to do that.

At this point, I decided to go into the Haskell tree and find the first version of GHC that will work with LLVM-18, which is what equery says I have installed. With dev-lang/ghc-9.4.7 unmasked and the llvm use flag set, I attempted to emerge GHC one more time.

Code: Select all

# emerge --ask --autounmask =dev-lang/ghc-9.4.7
[ebuild  N    ] dev-lang/ghc-9.4.7 
[ebuild  N    ] app-admin/haskell-updater-1.4.1.0 

And... nope:

Code: Select all

 * Please try emerging with USE=ghcbootstrap and report build
 * success or failure to the haskell team (haskell@gentoo.org)
 * ERROR: dev-lang/ghc-9.4.7::haskell failed (setup phase):
 *   No binary available for 'arm64' arch yet, USE=ghcbootstrap
 * 
 * Call stack:
 *          ebuild.sh, line 136:  Called pkg_setup
 *   ghc-9.4.7.ebuild, line 475:  Called die
 * The specific snippet of code:
 *   			die "No binary available for '${ARCH}' arch yet, USE=ghcbootstrap"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/ghc-9.4.7::haskell'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/ghc-9.4.7::haskell'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/ghc-9.4.7/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/ghc-9.4.7/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-lang/ghc-9.4.7/empty'
 * S: '/var/tmp/portage/dev-lang/ghc-9.4.7/work/ghc-9.4.7'

What am I doing wrong here?

[pietinger]

Moved from Portage & Programming to Gentoo on ARM.

[logrusx]

Code: Select all

 *   No binary available for 'arm64' arch yet, USE=ghcbootstrap

That means there's no binary ghc built on arm64.

Attempts to build it with bootstrap enabled fail:
...
What I've learned so far:

• The bootstrap keyword isn't an option to build GHC from a C compiler as one might expect.

There's no bootstrap use flag for ghc. It's ghcbootstrap:

Code: Select all

 - - ghcbootstrap   : Internal: Bootstrap GHC from an existing GHC installation.

• If I understand correctly, with the llvm flag enabled GHC should build but it requires a version of LLVM <=14 in order to do that.

Unfortunately you don't understand correctly. Why don't you look at the description of the useflags?

Code: Select all

- - llvm           : Pull in dependencies for the sys-devel/llvm codegen backend.

Best Regards,
Georgi

p.s. I think there might have been a similar thread.
p.s.2. here it is, I hope it helps: viewtopic-t-1150787.html

[jgaz]

Yeah, pardon my typo you're correct it's ghcbootstrap. That's the flag I enabled. I fixed my typo in my original post.

I did look at the keyword descriptions, I took "sys-devel/llvm codegen backend" to mean that GHC would generate code (compile the ebuild) using LLVM as the backend instead of GCC.

If nobody can build dev-lang/ghc on ARM64, why is it ~amd64 in the portage tree? If what you say is true, the ebuild should be marked as -arm64.

[pingtoo]

jgaz,

I think the ebuild does not require LLVM, it is optional.

It look to me it is possible get binary by

Code: Select all

USE='binary ...' emerge -1a dev-lang/ghc

OR if you prefer build from source

Code: Select all

USE='-binary -llvm ...' emerge -1a dev-lang/ghc

[logrusx]

I took "sys-devel/llvm codegen backend" to mean that GHC would generate code (compile the ebuild) using LLVM as the backend instead of GCC.

LLVM is not a compiler. It's a backend for compilers. It'll make ghc use LLVM as the backend instead maybe its own, I don't know. From what I understand, it's used to generate the binary code that'll actually run on your CPU, not the binary executable of ghc. In other words, that's what'll generate instructions for the CPU from your Haskell programs.

EDIT: I just checked. What will llvm use flag do is make ghc generate LLVM IR(intermediate representation) which then LLVM will translate to instructions for the CPU. Nothing to do with compiling ghc.

Did you read my post before or after the edits I made? See the link at the bottom.

The ebuild only downloads amd64 binary, it doesn't handle arm64 case. I think if the tips Neddy has shared in that link do not help you, nothing can.

jgaz,

I think the ebuild does not require LLVM, it is optional.

It look to me it is possible get binary by

Code: Select all

USE='binary ...' emerge -1a dev-lang/ghc

OR if you prefer build from source

Code: Select all

USE='-binary -llvm ...' emerge -1a dev-lang/ghc

Did you try this on arm64? I don't see where you took the binary use flag from. How do you know it's what is necessary? Only guessing?

Best Regards,
Georgi

[pingtoo]

Did you try this on arm64? I don't see where you took the binary use flag from. How do you know it's what is necessary? Only guessing?

No I did not try that myself. But

See https://packages.gentoo.org/packages/dev-lang/ghc, there is "binary" USE flag.

And "9.2.8.ebuild"

Code: Select all

# Binaries created and uploaded by hololeap
SRC_URL_HOLOLEAP="https://eidetic.codes"
ghc_binaries_hololeap() {
	echo "
		binary? ( ${SRC_URL_HOLOLEAP}/${PN}-bin-${BIN_PVR}-${1}.gpkg.tar )
		!binary? ( ${SRC_URL_HOLOLEAP}/${PN}-bin-${BUILD_BIN_PVR}-${1}.gpkg.tar )
	"
}

# Binaries created and uploaded by matoro
SRC_URL_MATORO="https://github.com/matoro/${PN}/releases/download"
ghc_binaries_matoro() {
	echo "
		binary? ( ${SRC_URL_MATORO}/${BIN_PVR}/${PN}-bin-${BIN_PVR}-${1}.gpkg.tar )
		!binary? ( ${SRC_URL_MATORO}/${BUILD_BIN_PVR}/${PN}-bin-${BUILD_BIN_PVR}-${1}.tar.gz )
	"
}

And https://github.com/matoro/ghc/releases/tag/9.2.8

[jgaz]

Did you try this on arm64? I don't see where you took the binary use flag from. How do you know it's what is necessary? Only guessing?

No I did not try that myself. But

See https://packages.gentoo.org/packages/dev-lang/ghc, there is "binary" USE flag.

You're on to something, but when I try it it fails... and I think I know why!

The binary is located at https://github.com/matoro/ghc/releases/download/9.2.8/ghc-bin-9.2.8-aarch64-unknown-linux-gnu.gpkg.tar.

But the ebuild is looking for it at:

Code: Select all

${SRC_URL_MATORO}/${BIN_PVR}/${PN}-bin-${BIN_PVR}-${1}.gpkg.tar

Bottom line I'm 99% certain that bin-${BIN_PVR} should read bin-${BIN_PV} and it that would allow it to work. With ${BIN_PVR} present it's passing 9.0.2-r4 as part of the URL when it should be passing 9.0.2 instead.

[wjb]

Bug 928874 - the tinderbox found this back in April

[jgaz]

Bug 928874 - the tinderbox found this back in April

Well, nuts.

It looks like I can't have GHC installed on arm64 until this bug gets fixed. I use pandoc fairly frequently and I want to try hledger as well, both are written in Haskell.

How do I politely raise the visibility of this bug to the Haskell folks?

[logrusx]

Did you try Neddy's suggestion from the thread I linked?

Best Regards,
Georgi

[jgaz]

Did you try Neddy's suggestion from the thread I linked?

Best Regards,
Georgi

Not yet I haven't. I was looking at the possibility of using Homebrew to accomplish basically the same thing, but it's x86_64 only.

[wjb]

It looks like I can't have GHC installed on arm64 until this bug gets fixed.

Well, actually ...

• Edit the ebuild file and confirm it builds
• Attach your ebuild file to the bug with suitable comment
• Create a personal overlay with your version of the ebuild in it, till it gets fixed

[pingtoo]

Bug 928874 - the tinderbox found this back in April

Well, nuts.

The bug is unrelated to the binary file. It is trying to install using the ebuild file. It does not mean binary does not work.

I managed install the binary .gpkg.tar file. (did this in docker container. You don't have to in container. I just want to test install procedure.)

Steps,

1. Download from https://github.com/matoro/ghc/releases/ ... u.gpkg.tar
2. cp ghc-bin-9.2.8-aarch64-unknown-linux-gnu.gpkg.tar /var/cache/binpkgs/dev-lang/ghc-9.2.8.pkg.tar
3. emaint binhost --fix
4. emerge -1K ghc

Code: Select all

4d7f337e78c0 /var/cache/binpkgs # ghc --help
Usage:

    ghc [command-line-options-and-input-files]

To compile and link a complete Haskell program, run the compiler like
so:

    ghc Main

where the module Main is in a file named Main.hs (or Main.lhs) in the
current directory.  The other modules in the program will be located
and compiled automatically, and the linked program will be placed in
the file `Main' (or `Main.exe' on Windows).

Alternatively, ghc can be used to compile files individually.  Each
input file is guided through (some of the) possible phases of a
compilation:

    - unlit:	extract code from a "literate program"
    - hscpp:	run code through the C pre-processor (if -cpp flag given)
    - hsc:	run the Haskell compiler proper
    - gcc:	run the C compiler (if compiling via C)
    - as:	run the assembler
    - ld:	run the linker

For each input file, the phase to START with is determined by the
file's suffix:

    - .lhs	literate Haskell		 unlit
    - .hs	plain Haskell			 ghc
    - .hc	C from the Haskell compiler	 gcc
    - .c	C not from the Haskell compiler  gcc
    - .s	assembly language		 as
    - other	passed directly to the linker	 ld

The phase at which to STOP processing is determined by a command-line
option:

    -E		stop after generating preprocessed, de-litted Haskell
		     (used in conjunction with -cpp)
    -C		stop after generating C (.hc output)
    -S		stop after generating assembler (.s output)
    -c		stop after generating object files (.o output)

Other commonly-used options are:

    -v[n]	    Control verbosity (n is 0--5, normal verbosity level is 1,
	              -v alone is equivalent to -v3)

    -O		    An `optimising' package of compiler flags, for faster code

    -prof	    Compile for cost-centre profiling
		     (add -fprof-auto for automagic cost-centres on all
		      top-level functions)

    -H14m	    Increase compiler's heap size (might make compilation
		    faster, especially on large source files).

    -M              Output Makefile rules recording the
		    dependencies of a list of Haskell files.

Given the above, here are some TYPICAL invocations of ghc:

    # compile a Haskell module to a .o file, optimising:
    % ghc -c -O Foo.hs
    # link three .o files into an executable called "test":
    % ghc -o test Foo.o Bar.o Baz.o
    # compile a Haskell module to C (a .hc file), using a bigger heap:
    % ghc -C -H16m Foo.hs
    # compile Haskell-produced C (.hc) to assembly language:
    % ghc -S Foo.hc

The User's Guide has more information about GHC's *many* options.  An
online copy can be found here:

   http://www.haskell.org/ghc/docs/latest/html/users_guide/

If you *really* want to see every option, then you can pass
'--show-options' to the compiler.

------------------------------------------------------------------------
4d7f337e78c0 /var/cache/binpkgs # 

Installation notes,

• You most likely need to install all the dependencies. I did it force without any dependency.
• The emerge command is unlikely be the one you use, It is just there to demonstrate.
• gpkg.tar file copy destination is /var/cache/binpkgs/dev-lang/
• gpkg.tar file name was shorten to ghc-9.2.8.gpkg.tar
• If you don't have /var/cache/binpkgs/Packages file exist before run emaint. then touch /var/cache/binpkgs/Packages && chown portage:portage -R /var/cache/binpkgs/*

[jgaz]

Thanks! I'll give this a try in a bit.