View previous topic :: View next topic |
Author |
Message |
jgaz n00b
Joined: 14 Feb 2021 Posts: 48
|
Posted: Sat Nov 09, 2024 6:37 pm Post subject: Trying to emerge dev-lang/ghc on arm64 without much luck |
|
|
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: |
# 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: |
* 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: |
* 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:
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: |
# 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: |
* 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?
Last edited by jgaz on Sat Nov 09, 2024 7:08 pm; edited 1 time in total |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5147 Location: Bavaria
|
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2453
|
Posted: Sat Nov 09, 2024 7:00 pm Post subject: Re: Trying to emerge dev-lang/ghc on arm64 without much luck |
|
|
jgaz wrote: |
Code: |
* No binary available for 'arm64' arch yet, USE=ghcbootstrap
|
|
That means there's no binary ghc built on arm64.
jgaz wrote: | 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: | - - ghcbootstrap : Internal: Bootstrap GHC from an existing GHC installation. |
jgaz wrote: |
- 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: | - - 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: https://forums.gentoo.org/viewtopic-t-1150787.html |
|
Back to top |
|
|
jgaz n00b
Joined: 14 Feb 2021 Posts: 48
|
Posted: Sat Nov 09, 2024 7:16 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1271 Location: Richmond Hill, Canada
|
Posted: Sat Nov 09, 2024 7:42 pm Post subject: |
|
|
jgaz,
I think the ebuild does not require LLVM, it is optional.
It look to me it is possible get binary by Code: | USE='binary ...' emerge -1a dev-lang/ghc |
OR if you prefer build from source Code: | USE='-binary -llvm ...' emerge -1a dev-lang/ghc |
|
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2453
|
Posted: Sat Nov 09, 2024 7:46 pm Post subject: |
|
|
jgaz wrote: | 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.
pingtoo wrote: | jgaz,
I think the ebuild does not require LLVM, it is optional.
It look to me it is possible get binary by Code: | USE='binary ...' emerge -1a dev-lang/ghc |
OR if you prefer build from source Code: | 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 |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1271 Location: Richmond Hill, Canada
|
Posted: Sat Nov 09, 2024 10:43 pm Post subject: |
|
|
logrusx wrote: | 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: |
# 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 |
|
Back to top |
|
|
jgaz n00b
Joined: 14 Feb 2021 Posts: 48
|
Posted: Sun Nov 10, 2024 1:09 am Post subject: |
|
|
pingtoo wrote: | logrusx wrote: | 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: |
${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. |
|
Back to top |
|
|
wjb l33t
Joined: 10 Jul 2005 Posts: 633 Location: Fife, Scotland
|
Posted: Sun Nov 10, 2024 9:16 am Post subject: |
|
|
Bug 928874 - the tinderbox found this back in April |
|
Back to top |
|
|
jgaz n00b
Joined: 14 Feb 2021 Posts: 48
|
Posted: Sun Nov 10, 2024 4:06 pm Post subject: |
|
|
wjb wrote: | 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? |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2453
|
Posted: Sun Nov 10, 2024 4:28 pm Post subject: |
|
|
Did you try Neddy's suggestion from the thread I linked?
Best Regards,
Georgi |
|
Back to top |
|
|
jgaz n00b
Joined: 14 Feb 2021 Posts: 48
|
Posted: Sun Nov 10, 2024 7:18 pm Post subject: |
|
|
logrusx wrote: | 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. |
|
Back to top |
|
|
wjb l33t
Joined: 10 Jul 2005 Posts: 633 Location: Fife, Scotland
|
Posted: Sun Nov 10, 2024 8:04 pm Post subject: |
|
|
jgaz wrote: | 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
|
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1271 Location: Richmond Hill, Canada
|
Posted: Sun Nov 10, 2024 10:03 pm Post subject: |
|
|
jgaz wrote: | wjb wrote: | 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,- Download from https://github.com/matoro/ghc/releases/tag/9.2.8/ghc-bin-9.2.8-aarch64-unknown-linux-gnu.gpkg.tar
- cp ghc-bin-9.2.8-aarch64-unknown-linux-gnu.gpkg.tar /var/cache/binpkgs/dev-lang/ghc-9.2.8.pkg.tar
- emaint binhost --fix
- emerge -1K ghc
On RPI 4: | 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/*
|
|
Back to top |
|
|
jgaz n00b
Joined: 14 Feb 2021 Posts: 48
|
Posted: Sun Nov 10, 2024 10:08 pm Post subject: |
|
|
Thanks! I'll give this a try in a bit. |
|
Back to top |
|
|
|