- Glasgow-haskell-users

is cabal-install buildable?
by Evan Laforge 29 Mar '20

29 Mar '20

I recently upgraded to ghc 8.8.3, thinking that since it's been around 8 months and 8.10 is already out, maybe things have stabilized enough. But I immediately ran into confusing trouble with cabal-install. It seems like it's just not buildable since 8.8 came out. Can this really be true? The reason is that from 2.4.0.0 onwards, it requires base <=4.13, and 8.8 uses base-4.13. Oddly, 2.2.0.0 claims support up to base 5, but actually not, because it also requires stm <2.5, and 8.8 uses stm 2.5, and it's a bootlib. I thought maybe the new nix-style build was supposed to no longer require version matches for bootlibs, but since `cabal v2-configure` fails I guess it must still have that requirement. In any case, my understanding is that linking to different versions of bootlibs isn't a good idea anyway, because once you have a dependency on the ghci api you're stuck. I looked into how nixpkgs builds cabal-install, and it looks like it disables version constraints, pulls a patch for hackage-security from hvr's personal github. So it is buildable, if you apply custom patches. Of course in the limit that's true of everything! I guess we don't need source builds to work as long as someone somewhere can figure out how to do the build and upload a binary, so I downloaded the pre-built binary of 3.0.0.0 from https://www.haskell.org/cabal/download.html, and it seemed to work at first. However, it couldn't build a particular package, and when I tried to download and `cabal configure` it, I got a version conflict which was not very clear, but the important line seems to be this: [__1] rejecting: hlibgit2:setup.Cabal-3.0.1.0/installed-3.0..., hlibgit2:setup.Cabal-3.0.0.0, hlibgit2:setup.Cabal-2.4.1.0, hlibgit2:setup.Cabal-2.4.0.1, hlibgit2:setup.Cabal-2.4.0.0 (conflict: hlibgit2 => hlibgit2:setup.Cabal>=1.10 && <1.25) My best guess about what this means is that, while hlibgit2 has no explicit dependency on Cabal (the library), it does have a Setup.hs, which imports Distribution.Simple, and perhaps this creates a dependency, and the ghc 8.8.3 has `Cabal-3.0.1.0` while cabal-install was compiled against `Cabal-3.0.0.0`, and I vaguely remember if you use a cabal-install whose Cabal version doesn't match the Cabal version of the ghc you are using, it will appear to work, until it doesn't, and then things will crash with confusing errors, or rebuild constantly, or do something bad. But of course I can't compile cabal-install against Cabal-3.0.1.0 because I can't build it at all. Maybe it actually is important for source builds to work! It looks like I could downgrade to 8.8.1 and maybe things would work. Is this really the situation? If it's not, where did I go wrong? If it is, how can we fix it? Provided people agree it's a problem, but if not, why not? I seem to recall that just about every ghc release has had this kind ghc-Cabal-cabal-install synchronization problem, and it's one of the reasons I wait 6 months or so before upgrading. But of course that's not good for me or for ghc, because then I'm reporting the bugs rather late.

1 0

Re: [ANNOUNCE] GHC 8.8.3 is now available
by Ben Gamari 29 Feb '20

29 Feb '20

Ben Gamari <ben(a)well-typed.com> writes: > --text follows this line-- > <#part sign=pgpmime> > > Hello everyone, > > The GHC team is proud to announce the release of GHC 8.8.3. The source > distribution, binary distributions, and documentation are available at > > https://downloads.haskell.org/~ghc/8.8.3 > > Release notes are also available [1]. > Unfortunately there has been a slight mix-up in the binary distributions associated with this release and I will need to do a re-spin. I have pulled down the binary distributions for the time being. They should be back in a few hours. Many apologies for the confusion! Cheers, - Ben

2 2

[ANNOUNCE] GHC 8.8.2 is now available
by Ben Gamari 25 Feb '20

25 Feb '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.2. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.2 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.1: - A bug (#17088) in the compacting garbage collector resulting in segmentations faults under specific circumstances. Note that this may affect user programs even if they did not explicitly request the compacting GC (using the -c RTS flag) since GHC may fallback to compacting collection during times of high memory pressure. - A code generation bug (#17334) resulting in GHC panics has been fixed. - A bug in the `process` library causing builds using `hsc2hs` to fail non-deterministically on Windows has been fixed (Trac #17480) - A typechecker bug (#12088) resulting in programs being unexpectedly rejected has been fixed. - A bug in the implementation of compact normal forms resulting in segmentation faults in some uses (#17044) has been fixed. - A bug causing GHC to incorrectly complain about incompatible LLVM versions when using LLVM 7.0.1 has been fixed (#16990). As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.2/docs/html/users_guide/8.8.2-notes.h…

2 3

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released
by Ben Gamari 26 Jan '20

26 Jan '20

Hello all, The GHC team is happy to announce the availability of the first release candidate of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-rc1/ GHC 8.10.1 will bring a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events This is the first and likely final release candidate. For a variety of reasons, it comes a few weeks later than the original schedule of release late December. However, besides a few core libraries book-keeping issues this candidate is believed to be in good condition for the final release. As such, the final 8.10.1 release will likely come in two weeks. Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. In addition, we are still looking for any Alpine Linux to help diagnose the correctness issues in the Alpine binary distribution [1]. If you use Alpine any you can offer here would be greatly appreciated. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

4 3

GHC Full Bootstrap from Source on macOS
by Steven Smith 19 Jan '20

19 Jan '20

Is there a guide or script to build ghc from source (not the prebuilt binary)? At MacPorts we’re running into issues on macOS Catalina 10.15 with the bootstrapped-from-prebuilt ghc. See https://trac.macports.org/ticket/59467 . It would preferable and probably more robust to be able to bootstrap everything from source, and highly preferable to be able to do this with a clang compiler of choice.

1 0

GHC 8.8.2 Bootstrap Build Fails on macOS Catalina 10.15, undeclared identifier 'TAG_MASK'
by Steven Smith 17 Jan '20

17 Jan '20

I’m trying to upgrade the MacPorts ghc install to the latest 8.8.2. The build fails with: > error: use of undeclared identifier 'TAG_MASK' > :info:build return (StgWord)p & TAG_MASK; This is an error observed with previous ghc versions and on other systems, so I do not believe it is macOS-specific. Also, the MacPorts build process simply follows the ghc Build & Install instructions: https://github.com/ghc/ghc/blob/master/README.md#building--installing Is there a simple fix by adding an extra flag somewhere? Logs: > :info:build In file included from compiler/ghci/keepCAFsForGHCi.c:1:0: error: > :info:build In file included from includes/Rts.h:191:0: error: > :info:build includes/rts/storage/ClosureMacros.h:211:25: error: > :info:build error: use of undeclared identifier 'TAG_MASK' > :info:build return (StgWord)p & TAG_MASK; > :info:build ^ > :info:build | > :info:build 211 | return (StgWord)p & TAG_MASK; > :info:build | ^ > :info:build includes/rts/storage/ClosureMacros.h:217:40: error: > :info:build error: use of undeclared identifier 'TAG_MASK' > :info:build return (StgClosure*)((StgWord)p & ~TAG_MASK); > :info:build ^ > :info:build | > :info:build 217 | return (StgClosure*)((StgWord)p & ~TAG_MASK); > :info:build | ^ > :info:build includes/rts/storage/ClosureMacros.h:223:46: error: > :info:build error: use of undeclared identifier 'TAG_MASK' > :info:build return (const StgClosure*)((StgWord)p & ~TAG_MASK); > :info:build ^

2 1

[ANNOUNCE] GHC 8.8.2-rc1 is now available
by Ben Gamari 02 Jan '20

02 Jan '20

Hello everyone, The GHC team is proud to announce the first release candidate of GHC 8.8.2. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.2-rc1 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.1: - A bug (#17088) in the compacting garbage collector resulting in segmentations faults under specific circumstances. Note that this may affect user programs even if they did not explicitly request the compacting GC (using the -c RTS flag) since GHC may fallback to compacting collection during times of high memory pressure. - A code generation bug (#17334) resulting in GHC panics has been fixed. - A bug in the `process` library causing builds using `hsc2hs` to fail non-deterministically on Windows has been fixed (Trac #17480) - A typechecker bug (#12088) resulting in programs being unexpectedly rejected has been fixed. - A bug in the implementation of compact normal forms resulting in segmentation faults in some uses (#17044) has been fixed. - A bug causing GHC to incorrectly complain about incompatible LLVM versions when using LLVM 7.0.1 has been fixed (#16990). As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.2-rc1/docs/html/users_guide/8.8.2-not…

3 2

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-alpha2 released
by Ben Gamari 02 Jan '20

02 Jan '20

Hello all, The GHC team is happy to announce the availability of the first alpha release in the GHC 8.10 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-alpha2/ GHC 8.10.1 will bring a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events This release is the second alpha of the 8.10 pre-release cycle. The release will be a release candidate in roughly three weeks. If all goes well the final release will be cut roughly two weeks after the candidate, in mid-January. This being an alpha release, there are a few issues that are still outstanding: * The new Alpine Linux binary distribution is not present due to an apparent correctness issue [1]; any help Alpine users can offer here would be greatly appreciated. * We have yet to sort out compliance with Apple's notarization requirements [2] which will be likely be necessary for users of macOS Catalina. However, until this has been sorted out Catalina users can exempt the current macOS binary distribution from the notarization requirement themselves by running `xattr -cr .` on the unpacked tree before running `make install`. * There is one remaining non-regression correctness issue which we plan to fix for the final 8.10.1 but that is not fixed in this release. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

2 1

GHC 8.8.1 Fails to Build on macOS with Native clang 11.0.0
by Steven Smith 23 Dec '19

23 Dec '19

I’m trying to update the MacPorts ghc port. The build isn’t getting the TAG_MASK #define for some reason, which breaks the build. The previous release ghc 8.6.5 builds successfully. I’m following the simple build instructions here: https://github.com/ghc/ghc#building--installing <https://github.com/ghc/ghc#building--installing> # Use prebuilt bootstrap ghc binary export GHC='/opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/bootstrap/bin/ghc’ ./boot ./configure make -j7 Error: > Creating compiler/stage2/build/Config.hs ... > > In file included from compiler/parser/cutils.c:6:0: error: > > In file included from includes/Rts.h:191:0: error: > > includes/rts/storage/ClosureMacros.h:211:25: error: > error: use of undeclared identifier 'TAG_MASK' > return (StgWord)p & TAG_MASK; > ^ > | > 211 | return (StgWord)p & TAG_MASK; > | ^ > … > make[1]: *** [compiler/stage1/build/cbits/genSym.o] Error 1 > <<ghc: 5147183728 bytes, 749 GCs, 27001343/62810440 avg/max bytes residency (18 samples), 150M in use, 0.001 INIT (0.004 elapsed), 2.217 MUT (2.637 elapsed), 1.677 GC (1.738 elapsed) :ghc>> > make: *** [all] Error 2 I’m using the macOS native clang: $ which clang /usr/bin/clang $ clang --version Apple clang version 11.0.0 (clang-1100.0.33.16) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

1 1

downloads.haskell.org server is misconfigured, ignores Accept-Encoding, prevents update checks
by Steven Smith 23 Dec '19

23 Dec '19

The downloads.haskell.org server is misconfigured. It's always gzipping its response content, ignoring the Accept-Encoding headers. Even if you set Accept-Encoding: identity the server sends a compressed response. This prevents automated version update checking. For details, see: https://lists.macports.org/pipermail/macports-dev/2019-December/041581.html <https://lists.macports.org/pipermail/macports-dev/2019-December/041581.html>

1 0