Trouble building GHC
Georgi Lyubenov
godzbanebane at gmail.com
Wed May 31 07:49:37 UTC 2023
Just chiming in to mention that I'm on zsh, and I've had no issues with
the configure step by running the configure_ghc shell function that the
flake provides.
On 5/31/23 10:13, Sebastian Graf wrote:
> Hi Lyle,
>
> I'm sorry that you have so much trouble in getting your first build done.
> The Classes.hi issue sounds like something I had experienced in the
> past, but I'm not having it at the moment.
> Are you also using symlinks by any chance? Then it is very likely that
> you have been bitten by
> https://gitlab.haskell.org/ghc/ghc/-/issues/22451, the workaround to
> which would be to do something like `cd "$(readlink -f .)"` before you
> start your build.
>
> Regarding your second issue using ghc.nix, a quick google turned up
> https://gitlab.haskell.org/ghc/ghc/-/issues/20429#note_379762.
> Is it possible that you didn't start from a clean build?
> E.g., at the least you should `rm -rf _build` (note that
> `hadrian/cabal clean` sadly is insufficient IIRC for reasons I don't
> recall).
> I often simply do `git clean -fxd` to be extra sure.
> After that, you'll have to boot, configure (including passing
> $CONFIGURE_ARGS) and build again.
> By the way, are you using ZSH? I'm using it and I have topass the
> CONFIGURE_ARGS in a slightly different way
> <https://github.com/alpmestan/ghc.nix#building-ghc>: `./configure
> ${=CONFIGURE_ARGS}`.
>
> I also updated
> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/linux#nixnixos
> to account for new-style flakified builds+direnv, if that's a workflow
> that you are familiar with.
>
> Hope that helps,
> Sebastian
>
> Am Mi., 31. Mai 2023 um 05:14 Uhr schrieb Lyle Kopnicky <lists at qseep.net>:
>
> Hi folks, I’m new here. I’ll be attending the GHC Contributors’
> Workshop next week, and in preparation, I’m trying to build GHC,
> both the native code backend and the JS backend. So far, I’ve only
> tried to build it with the native code backend, but I haven’t been
> able to get it to work. I’ve gotten help from some friendly folks
> on the #ghc channel on Matrix, and made some progress, but I’m
> still stuck.
>
> Is there anyone here who could be a point person for helping me
> get it to build? BTW I’m located on the west coast of the US
> (until next week when I’ll be in Switzerland), so time lag may be
> a factor.
>
> I’m using a Mac with aarch64 and macOS 13.3. Here are some of the
> things I’ve tried, and issues I’ve run into:
>
> * Started with the advice from this wiki:
> https://gitlab.haskell.org/ghc/ghc/-/wikis/building
> * Checked out the ghc source, on HEAD.
> * The rest of the steps were at
> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx
> * Already had Apple’s command line tools, but when I tried to do
> operations using them, I got an error saying I needed the full
> Xcode, so I installed that.
> * brew install autoconf automake python sphinx-doc
> o Worked fine, also added sphinx-build to the path
> * Initially tried using ghc 9.2.7 to build - later tried
> switching to 9.4.4 and eventually 9.4.5
> * cabal update; cabal install alex happy haddock
> o This is where I ran into trouble - couldn’t build haddock.
> Cabal said it couldn’t resolve the dependencies.
> o I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same
> problem
> o User romes (Rodrigo) on #ghc helped with this - was able
> to reproduce it and filed a ticket:
> https://github.com/haskell/haddock/issues/1596
> o However he pointed out that haddock was already supplied
> through ghcup so I don’t need to build it.
> * Already had MacTex installed and I installed the DejaVu font
> family.
> * ./boot && ./configure
> o Worked fine, although |./boot| gave me lots of autoconf
> warnings like:
> configure.ac:9 <http://configure.ac:9>: warning: The macro
> `AC_HELP_STRING' is obsolete.
> configure.ac:9 <http://configure.ac:9>: You should run
> autoupdate.
> o Apparently autoconf has renamed these macros to pluralize
> them, and also encloses the arguments in square brackets.
> * hadrian/build
> o Ran into another problem: The build failed with:
> Error, file does not exist and no rule available:
> /Users/lyle/devel/haskell/ghc/_build/stage1/libraries/ghc-prim/build/GHC/Classes.hi
> o Rodrigo helped me out with this. Introduced me to other
> build flags like |-j —flavour-quick|.
> o The issue proved quite persistent, but it might fail on
> different |.hi| files.
> o It turns out if you ask Hadrian to build that specific
> file, it works. So somehow it can find a rule! Then you
> can proceed to rebuild and it will fail on a different
> |.hi| file. Obviously it would be tedious to do this for
> all the possible files it can fail on.
> o I also tried not building profiled libraries.
> o I tried, instead of using the Apple toolchain, using llvm
> 12, then llvm 16. But I got different errors from that.
> o Rodrigo was unable to reproduce the issue.
> * So, I thought I’d try the Nix approach.
> * First I had to repair my nix installation, because apparently
> updating macOS overwrites /etc/zshrc, overwriting the bit that
> sources
> '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh’
> * Nix reminded me when I ran commands that I needed to add the
> flag '--extra-experimental-features nix-command’ and
> sometimes '--extra-experimental-features flakes’
> * The instructions from the wiki
> <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx>
> didn’t work, got an error:
> o
>
> o nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh
> --extra-experimental-features nix-command
> o error: cannot evaluate a function that has an argument
> without a value ('system’)
> * But folks on #ghc recommended I use |ghc.nix| instead
> o Pointed me to https://ghc.dev/
> o That linked to these instructions:
> https://github.com/alpmestan/ghc.nix#building-ghc
> o But those instructions failed with:
> + error: nix-shell requires a single derivation
> o User Artem said my command was wrong, instead recommended:
> + nix develop
> https://github.com/alpmestan/ghc.nix/archive/master.tar.gz
> o Once I added the magic experimental flags…
> o It failed, with:
> + error: NAR hash mismatch in input
> 'github:commercialhaskell/all-cabal-hashes/02bb1361217e690d83af9cc132b1d2bf2096763c'
> (/nix/store/zbav3qqbyz7mn7rh4iwybs0ni01ppdbj-source),
> expected
> 'sha256-HdAnlSc4U8ftnZrBZr2CewsPQs03V9K2gkTVHKG8IfA=',
> got 'sha256-86BgvJ+ebMxTp+nPxo659hsNJbhE6CYJWiIbQXX+sBM=
> o User MangoIV helped me out with this.
> o First I tried regenerating the lock file, with |nix flake
> update|.
> + Didn’t fix the problem.
> o Then, I checked out the branch update_flake_lock_action
> + This is apparently a branch designed to fix the problem
> + Didn’t fix the problem
> o Then I regenerated the lock file again, with |nix flake
> update|
> + That worked! Well, at least that got me to a
> |ghc.nix| prompt
> o So, I did:
> + ./boot
> + ./configure
> + cabal v2-update
> + hadrian/build -j --flavour=quick
> o It chugged along for quite a while. Sadly, it ended with
> this error:
> +
>
> + Linking
> /Users/lyle/Sync/devel/haskell/ghc/hadrian/dist-newstyle/build/aarch64-osx/ghc-9.2.4/hadrian-0.1.0.0/x/hadrian/build/hadrian/hadrian
> ...
> Data.Binary.Get.runGet at position 1181: Unknown
> encoding for constructor
> o What also worries me is that I thought I read somewhere
> that |ghc.nix| doesn’t work for cross-compilers, so even
> if it works for the native backend, it may not work for
> the JS backend.
>
>
> Any help would be much appreciated!
> — Lyle
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230531/57829bce/attachment.html>
More information about the ghc-devs
mailing list