Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

D-Locked · 2020-04-24 23:23:11

Hello,

I hope I am posting this in the right section. I noticed that the PKGBUILD for ghc includes 3 packages: 'ghc', 'ghc-libs' and 'ghc-static'.
However, on the 'makedepends' field, 'ghc-static' is also included (so it is a self-dependency).

Does anyone have any tips on how to proceed with building ghc* on a system where I cannot just install a previous version of 'ghc-static' with pacman?
(I use Archlinux ARM, where ghc* packages are not available in their official repos. However, I still thought it would be alright to ask in this forum, since the question targets the x86_64 PKGBUILD in community).

Thanks in advance!

Last edited by D-Locked (2020-04-24 23:49:53)

Xyne · 2020-04-25 00:35:16

mod note: Before the reports start accumulating, the issue itself is not related to ARM. Yes, with official Arch you can just bootstrap the build by installing ghc-static from the repos. but the general question of why there is a self-circular build dependency and how to deal it it is a legitimate question. If every ghc-static pacman package were to disappear right now, how would one recreate it?

I agree that dealing with a circular build dependency is a legitimate question on this forum and unrelated to Arch Linux ARM. It would be interesting to hear the package maintainer's suggestion.

In the absence of a better suggestion, I would try 2 things:

Disable and remove whatever I can in the PKGBUILD's configuration to remove any dependencies on ghc-static in the build process and then try to build it. If that works, install it, restore the PKGBUILD and rebuild everything.
Download and install the packages directly from upstream (https://www.haskell.org/ghc/download.html), remove ghc-static from the makedepends, build the package, restore the makedepends and then rebuild.

Both are unacceptably hackish pitas imo, but I'm hoping that there's a much more elegant solution. If not, wtf?

Last edited by Xyne (2020-04-25 00:40:20)

Trilby · 2020-04-25 00:41:10

It's certainly not the only package to have itself as a makedepends: even gcc does (via gcc-libs in the split package with a makedepends on gcc-libs).

In x86_64 arch, this is not a problem as the packages are in the repos so the new build can readily be built with those. But if your distros repos don't already include a binary package for at least ghc-static, then yes, you'll have to bootstrap it yourself following something like the options in Xyne's post. Alternatively, you could look into whether ghc can cross compile itself for another architecture. I suspect this is what the archARM people did for gcc when that got started: they built the archARM gcc on a running arch x86_64 (or i686 back in the day) system. From then on, the archARM gcc could compile itself.

In any case, this is why this is not really an arch question but is specific to archARM in my view.

Last edited by Trilby (2020-04-25 00:51:03)

loqs · 2020-04-25 00:50:03

Removing ghc-static then extra-x86_64-build

==> Starting build()...
checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC Git commit id... given 5c3cadf5db0d7eb859ff2c278ab07585c7df17b5
checking for ghc... no
configure: error: GHC is required.

https://github.com/ghc/ghc/blob/ghc-8.1 … re.ac#L149 really wants ghc to build ghc.

Looking at how gentoo does it from https://gitweb.gentoo.org/repo/gentoo.g … 0.1.ebuild that downloads a binary bundle for bootstrapping.
If that was not available upstream does provide some prebuilt binary packages https://www.haskell.org/ghc/download_ghc_8_10_1.html which unfortunately are not statically linked.
Edit:
https://gitlab.haskell.org/ghc/ghc/-/wi … ng/porting is no longer supported use cross compiling https://gitlab.haskell.org/ghc/ghc/-/wi … -compiling

Last edited by loqs (2020-04-25 02:39:18)

Allan · 2020-04-25 14:25:56

Xyne wrote:

Disable and remove whatever I can in the PKGBUILD's configuration to remove any dependencies on ghc-static in the build process and then try to build it. If that works, install it, restore the PKGBUILD and rebuild everything.
Download and install the packages directly from upstream (https://www.haskell.org/ghc/download.html), remove ghc-static from the makedepends, build the package, restore the makedepends and then rebuild.

3. Build an old version that did not have such a bootstrap requirement. Then start building more recent versions.

For gcc-ada, I tried 3, but it was a pain... so I grabbed a Fedora install and rebootstrapped our toolchain from scratch.

Xyne · 2020-04-25 20:41:32

Allan wrote:

For gcc-ada, I tried 3, but it was a pain... so I grabbed a Fedora install and rebootstrapped our toolchain from scratch.

And this is why we appreciate the devs

D-Locked · 2020-04-25 23:49:15

Thank you all, for your informative replies.

I now have some options to explore and it is certainly interesting to read about why self-circular dependencies exist and how they have been tackled by the devs!

Upon closer inspection, I found an AUR package ghc-raspbian-bin 7.10 (was looking specifically for 'static' before), which I have updated and installed. This comes with its own headaches from the ncurses package:

sudo ghc-pkg recache
/usr/lib/ghc/bin/ghc-pkg: /usr/lib/libtinfo.so.6: no version information available (required by /usr/lib/ghc/bin/ghc-pkg)

But I digress, as this specific issue is ARM-distro-specific and getting out of scope for these forums.

I will investigate the proposed options and come back to post an update when (if) I get this working.

Thanks!

eschwartz · 2020-04-26 05:11:17

https://bootstrappable.org/projects.html

See the section on ghc, it's a nightmare. Yes, this issue exists broadly speaking for any language, but as allan said, there's often a possibility to

3. Build an old version that did not have such a bootstrap requirement. Then start building more recent versions.

This is not the case for hasklol. Because hasklol is a sucky language with a sucky ecosystem and a sucky build system, and also, coincidentally, a sucky status w.r.t. compiler competition (i.e. they have none, which is why to build ghc you need ghc).

It's tremendously easier for any language which can bootstrap from C, since you have lots of options for a C compiler of varying quality including the bootstrappable.org sponsored GNU Mes / mescc (which is currently more primitive than its authors intend it to be, but which is written to be specifically useful for bootstrapping, so it's easy to build without external dependencies). C++ is also relatively easy, since there are multiple options for a C++ compiler and also because, as the bootstrappable.org project page describes, it's feasible to build gcc 4.7.4 with a C compiler: they use gcc 2.95, which in turn is built with tinycc, which in turn is built with minor patches using mescc because mescc is not yet mature enough to build code which uses all the C features tinycc does, i.e.

TCC is mostly implemented in C90. Do not use any non-C90 features
that are not already in use.

Non-C90 features currently in use, as revealed by
./configure --extra-cflags="-std=c90 -Wpedantic":

- long long (including "LL" constants)
- inline
- very long string constants
- assignment between function pointer and 'void *'
- "//" comments
- empty macro arguments (DEF_ASMTEST in i386-tok.h)
- unnamed struct and union fields (in struct Sym), a C11 feature

Xyne · 2020-04-26 13:28:43

eschwartz wrote:

This is not the case for hasklol. Because hasklol is a sucky language with a sucky ecosystem and a sucky build system, and also, coincidentally, a sucky status w.r.t. compiler competition (i.e. they have none, which is why to build ghc you need ghc).

I understand the sentiment and I would gladly chime in in disparaging some of the project's choices in private, but please refrain from making such remarks here. You know our code of conduct.

Arch Linux

#1 2020-04-24 23:23:11

Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#2 2020-04-25 00:35:16

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#3 2020-04-25 00:41:10

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#4 2020-04-25 00:50:03

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#5 2020-04-25 14:25:56

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#6 2020-04-25 20:41:32

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#7 2020-04-25 23:49:15

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#8 2020-04-26 05:11:17

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

#9 2020-04-26 13:28:43

Re: Difficulties on building Haskell (ghc*) with makepkg/PKGBUILD

Board footer