Glasgow-haskell-users

Download

glasgow-haskell-users@haskell.org

February 2024

3 participants
2 discussions

[ANNOUNCE] GHC 9.8.2 is now available
by Zubin Duggal 23 Feb '24

23 Feb '24

The GHC developers are happy to announce the availability of GHC 9.8.2. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_8_2.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html This release is primarily a bugfix release addressing many issues found in the 9.8 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for bugs in the renamer and typechecker (#24084, #24134, #24279, #24083) * Fixes for bugs in the simplifier and code generator (#24160, #24242, #23628, #23659, #24160, #23862, #24295, #24370) * Fixes for some memory leaks in GHCi (#24107, #24118) * Improvements to error messages (#21097, #16996, #11050, #24196, #24275, #23768, #23784, #23778) * A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724). * And many more fixes 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. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.2/docs/users_guide/9.8.2-notes.html

1 0

How to build executables that will dump live backtraces
by Clinton Mead 21 Feb '24

21 Feb '24

Hi All I've noticed this is a quiet mailing list recently, but I couldn't find a more appropriate place to ask this question. Please say if there's somewhere else I should be asking. It's my understanding that one can get GHC executables to dump backtraces of all their running threads to stderr upon receiving SIGQUIT. And the way to do that is to build with 'libdw' support. We have a build system using Nix, and we're unfortunately a bit behind on GHC 9.2.2 atm, but in anycase, I noticed in a Nix develop shell when I run `ghc --info | grep libdw` I get: ,("RTS expects libdw","NO") So I instead added the following to my Haskell package overrides: ghc = old.ghc.overrideAttrs (oldAttrs: { configureFlags = oldAttrs.configureFlags ++ [ "--with-libdw-includes=${pkgs.elfutils.dev}/include" "--with-libdw-libraries=${pkgs.elfutils.out}/lib" "--enable-dwarf-unwind" ]; buildInputs = oldAttrs.buildInputs ++ [pkgs.elfutils]; }); I basically copy/pastaed this from https://github.com/input-output-hk/haskell.nix/blob/master/compiler/ghc/def… And this seems to work, now when I run `ghc --info` I get: ,("RTS expects libdw","YES") But despite building with this version of GHC, still when I send `SIGQUIT` to a process built with this version of GHC, I just get the message: "This build does not support backtraces." Now I have also been building my packages with `-g`, passing `--enable-debug-info` etc, although it's my understanding that what I've done just with building GHC with `--enable-dwarf-unwind` _should_ be enough to get a backtrace upon SIGQUIT, it might just be a poor one if the debugging symbols aren't added. But clearly I've missed something if it's not working. I'm not quite sure what set of circumstances the message "This build does not support backtraces" is displayed? Is there a runtime check to see whether the "libdw" library is actually in the library path, in addition to the requirement that GHC be built with libdw support? If that's the case, perhaps as I'm running this on NixOS I need to add something to my executable's LD_LIBRARY_PATH or something? Or is there some option I need to give GHC/Cabal to ensure that backtrace support is added to the executable's runtime as well as making sure I've compiled with GHC that's compiled with libdw support? Or is there some other runtime RTS option I need to give to my executable? As you can see, I'm completely lost about how to move forward on this, so any help would be very much appreciated. Thanks, Clinton

2 1