- ghc-devs - Haskell.org

Trouble building GHC
by Lyle Kopnicky 04 Jun '23

04 Jun '23

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 - 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 - This is where I ran into trouble - couldn’t build haddock. Cabal said it couldn’t resolve the dependencies. - I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same problem - User romes (Rodrigo) on #ghc helped with this - was able to reproduce it and filed a ticket: https://github.com/haskell/haddock/issues/1596 - 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 - Worked fine, although ./boot gave me lots of autoconf warnings like: configure.ac:9: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:9: You should run autoupdate. - Apparently autoconf has renamed these macros to pluralize them, and also encloses the arguments in square brackets. - hadrian/build - 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 - Rodrigo helped me out with this. Introduced me to other build flags like -j —flavour-quick. - The issue proved quite persistent, but it might fail on different .hi files. - 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. - I also tried not building profiled libraries. - I tried, instead of using the Apple toolchain, using llvm 12, then llvm 16. But I got different errors from that. - 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: - - nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh --extra-experimental-features nix-command - error: cannot evaluate a function that has an argument without a value ('system’) - But folks on #ghc recommended I use ghc.nix instead - Pointed me to https://ghc.dev/ - That linked to these instructions: https://github.com/alpmestan/ghc.nix#building-ghc - But those instructions failed with: - error: nix-shell requires a single derivation - User Artem said my command was wrong, instead recommended: - nix develop https://github.com/alpmestan/ghc.nix/archive/master.tar.gz - Once I added the magic experimental flags… - 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= - User MangoIV helped me out with this. - First I tried regenerating the lock file, with nix flake update. - Didn’t fix the problem. - 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 - Then I regenerated the lock file again, with nix flake update - That worked! Well, at least that got me to a ghc.nix prompt - So, I did: - ./boot - ./configure - cabal v2-update - hadrian/build -j --flavour=quick - 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 - 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

6 12

help migrating a tool that uses the ghc api
by Sam Halliday 01 Jun '23

01 Jun '23

Hi all, A few years ago I wrote a tool (under a pseudonym) that uses the ghc api. I have not been working in Haskell and I've found that it's bitrotted since the 8.10.x series that I was most recently using. The impact of refactors to the ghc codebase have hit me really badly, and with the help of Sylvain, I've been able to get it to the point where it compiles with 9.0.2 and 9.2.7. I'm currently working my way through 9.4.5 support but this is becoming extremely time consuming and draining, so I'm asking for help from anybody who has been involved in these refactors if they could help further. There's only so much git pickaxe can help with, when functions names, types and parameters are moved around in a way that is hard to keep track of. Especially with the changes impacting the way packages, units, errors, and compiler invocation all work. The code is at https://gitlab.com/tseenshe/hsinspect (and also on hackage) and I'm doing all my work-in-progress under the ghc9 branch. As a follow up question, I have a few ideas for how this level of disruption to my codebase could be avoided and I was hoping to get some thoughts on it: 1. some programming language communities have a "community build" that is periodically built by snapshots of the compiler. This allows unexpected regressions to be caught early in the dev cycle and would allow the author of refactor changes to send a courtesy patch to keep the broken code running if the change is intended to be kept in the compiler. I'd like to propose hsinspect for such a community build. 2. propose that my code is merged into the ghc api, so that my code becomes trivial to maintain from that moment on because I've handed the responsibility on, very explicitly, to whoever wishes to make breaking changes in the compiler. I'd like to propose adding all my modules (minus the compiler plugin and machine readable format stuff) to the compiler code tree. are either of these options realistic? I don't think I would be interested in using Haskell anymore if my tooling stopped working: I've invested so much time and energy into it at this point that to start again or have to set my tools aside would be too much of a disincentive. I really love the Haskell language, so I hope that this is not the case. For those interested further in my tool and/or helping... As a quick architectural overview (motivations and goals are described well enough in the README to not need repeating): my tool is very simple: - the plugin is a ghc compiler plugin, all it does is dump out the flags that the batch compiler was invoked with. I understand that HLS has its own solution these days that involves extracting this information from the build tool, but I still prefer getting it from the compiler because it's simple, build tool agnostic, and guaranteed to be correct. I spent many years doing it the build tool route for Scala tooling and I think that was a mistake. - the runtime binary, which is user-invoked (rarely) during their dev cycle, and has several features. This binary is able parse the user's Haskell file's pragmas, on top of the flags that the compiler was invoked with, to extract the exact dflags to use for any interactive compiler usage. The specific features are then: - find all the packages that are depended upon by the home unit. Go and find all the symbols contained therein, including their type signatures. Dump it all out to a machine readable format. - parse just the imports section of the current file to extract the full list of imports in use. Then go and lookup all the symbol names that it implies and their package name, and dump it all out to a machine readable format. - parse the file, find all the data types that the user has defined, and output it into a simpler AST that is designed for code navigation and boilerplate generation tools, comments are not preserved. An example tool that can use this is at https://gitlab.com/tseenshe/boilerplate (and on hackage) On top of these machine readable files I have Emacs tooling that can provide me with all the semantic code editor support that I need, and leaves the door open for some things I haven't implemented yet (such as Hoogle like search within the project and dependencies). Code for the Emacs stuff is at https://gitlab.com/tseenshe/haskell-tng.el under the haskell-tng-hsinspect.el file The approach has some limitations, for example I cannot support RecordDotSyntax because completing on a dot would mean knowing the type under the dot. I also wrote an LSP so that my VSCode colleagues could use it too. Everybody that used it with me was free to use HIE (so called at the time) if they wished. Those of us who used hsinspect preferred it because it's basically zero overhead and is therefore really kind on CPU, RAM and battery life. -- Best regards, Sam

5 7

[Haskell] [ANNOUNCE] GHC 9.2.8 released
by Zubin Duggal 26 May '23

26 May '23

The GHC developers are happy to announce the availability of GHC 9.2.8. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.2.8). This release is primarily a bugfix release addressing one issue found in 9.2.7: - Fix a bug with RTS linker failing with 'internal error: m32_allocator_init: Failed to map' on newer Linux kernels (#19421). We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.8/docs/html/users_guide/9.2.8-notes.…

1 0

[ANNOUNCE] GHC 9.6.2 is now available
by Ben Gamari 24 May '23

24 May '23

The GHC developers are happy to announce the availability of GHC 9.6.2. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.2 This release is primarily a bug-fix release addressing a few issues found in 9.6.2. These include: * a number of simplifier and specialisation issues (#22761, #22549) * A bug resulting in crashes of programs using the new ``listThreads#`` primop (#23071). * A compiler crash triggered by certain uses of quantified constraints (#23171) * Various bugs in the Javascript backend have been fixed (#23399, #23360, #23346) * A missing write barrier in the non-moving collector's handling of selector thunks, resulting in undefined behavior (#22930). * The non-moving garbage collector's treatment of weak pointers has been revamped which should allow more reliable finalization of ``Weak#`` closures (#22327) * The non-moving garbage collector now bounds the amount of marking it will do during the post-marking stop-the-world phase, greatly reducing tail latencies in some programs (#22929) A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.2/docs/users_guide/9.6.2-notes.html

1 0

Release schedules: 9.6.2 and 9.8.1
by Matthew Pickering 12 May '23

12 May '23

Hi all, * We are preparing the 9.6.2 release to happen within 1-2 weeks. * The proposed 9.8.1 schedule is as follows: Fork Date: June 16th Release Date: Early September Feature patches not in the tree by June 16th will not be included in the release. This is the six-month release cadence which we have proposed to follow. Cheers, Matt

1 0

GHC GitLab change to login: disabling OAuth via GitHub
by Bryan Richter 07 May '23

07 May '23

Hi folks, Spammers have been abusing GitHub OAuth to create accounts on gitlab.haskell.org and post spam. Due to team resources, the only good way to stop spammers right now is to manually approve each new user. GitHub OAuth defeats that by automatically approving new users. So, sadly, I have disabled GitHub OAuth for the time being. If you used it to sign up and have trouble logging in now, one of us admins can help you out. -Bryan

2 2

Contributing packages?
by Dominick Samperi 04 May '23

04 May '23

I just tried to upload a new Haskell package and ran into some difficulties. If I just try to upload, it fails and says I need to contact somebody in the trustees group to be added to the Uploaders group. If I try to upload a package candidate instead, it says Forbidden, No access for this resource. The Uploading packages help page is not very helpful. Also, I have a Hackage account and I can get to the account management page, and generate an auth key, but I don't know what I can do with that. It seems the package candidate feature is the way to go, since direct uploads are irreversible and more difficult to manage. Any tips would be appreciated. Thanks, Dominick

1 0

Build of GHC 9.6 fails when the build directory is not a child of the source directory
by Viktor Dukhovni 01 May '23

01 May '23

For some time now I'd been unable to build GHC 9.6 from source. The reason turned out to be that my hadrian command-line selected an explicit build directory that was not an immediate child of the source directory (default it seems is "_build"). With the source tree under "$HOME/dev/ghc/", the hardrian command $ hadrian/build -V -V -o"$HOME/dev/buildghc" --docs=no-sphinx binary-dist-dir after building stage0, and running "configure" in libraries/base, reports an error finding HsFFI.h: Reading parameters from $HOME/dev/buildghc/stage1/libraries/base/build/base.buildinfo /usr/bin/cc '-fuse-ld=gold' /tmp/2303653-4.c -o /tmp/2303653-5 '-D__GLASGOW_HASKELL__=906' \ '-Dlinux_BUILD_OS=1' \ '-Dx86_64_BUILD_ARCH=1' \ '-Dlinux_HOST_OS=1' \ '-Dx86_64_HOST_ARCH=1' \ -I$HOME/dev/buildghc/stage1/libraries/base/build/autogen \ -I$HOME/dev/buildghc/stage1/libraries/base/build/include \ -Ilibraries/base/include \ -Ilibraries/base \ -I/usr/include \ -I$HOME/dev/buildghc/stage1/inplace/../../..//libraries/ghc-bignum/include/ \ -I$HOME/dev/buildghc/stage1/libraries/ghc-bignum/build/include/ \ -I$HOME/dev/buildghc/stage1/inplace/../../..//libraries/ghc-bignum/include \ -I$HOME/dev/buildghc/stage1/libraries/ghc-bignum/build/include \ -I$HOME/dev/buildghc/stage1/inplace/../../..//rts/include \ -I$HOME/dev/buildghc/stage1/rts/build/include \ '-I$HOME/dev/buildghc/stage1/inplace/../../..//rts/@FFIIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/rts/build/@FFIIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/inplace/../../..//rts/@LibdwIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/rts/build/@LibdwIncludeDir@' \ -L$HOME/dev/buildghc/stage1/inplace/../libraries/ghc-bignum/build \ -L$HOME/dev/buildghc/stage1/inplace/../libraries/ghc-prim/build \ -L$HOME/dev/buildghc/stage1/inplace/../rts/build -iquote \ $HOME/dev/ghc/libraries/base \ '-fuse-ld=gold' There are two issues to note here: - "hadrian" fails to substitute @FFIIncludeDir@ and @LibdwIncludeDir@. This used to be handled by "configure", but the job of turning "rts.cabal.in" into "rts.cabal" seems to have been reassigned to "hadrian". - With the build output directory a sibling rather than a child of the source tree, the path to "rts/include" is not constructed correctly. The path: -I$HOME/dev/buildghc/stage1/inplace/../../..//rts/include should have been: -I$HOME/dev/buildghc/stage1/inplace/../../../ghc/rts/include Switching to the default path proved to be a viable work-around, but perhaps other choices should also work. -- Viktor.

2 2

does llvm 16 work with ghc 9.6.1 ?
by George Colpitts 26 Apr '23

26 Apr '23

Hi Does anybody know if llvm 16 works with ghc 9.6.1 ? Thanks George

2 4

GHC 9.6.1 rejects previously working code
by Harendra Kumar 25 Apr '23

25 Apr '23

The following code compiles with older compilers but does not compile with GHC 9.6.1: {-# LANGUAGE KindSignatures #-} module A () where import Control.Monad.IO.Class import Control.Monad.Trans.Class data T (m :: * -> *) a = T instance Functor (T m) where fmap f T = undefined instance Applicative (T m) where pure = undefined (<*>) = undefined instance MonadIO m => Monad (T m) where return = pure (>>=) = undefined instance MonadTrans T where lift = undefined It fails with the following error: xx.hs:20:10: error: [GHC-39999] • Could not deduce ‘MonadIO m’ arising from the head of a quantified constraint arising from the superclasses of an instance declaration from the context: Monad m bound by a quantified context at xx.hs:20:10-21 Possible fix: add (MonadIO m) to the context of a quantified context • In the instance declaration for ‘MonadTrans T’ | 20 | instance MonadTrans T where | ^^^^^^^^^^^^ What is the correct resolution for this? -harendra

4 4