- Glasgow-haskell-users

What does freezing an array really do?
by David Feuer 21 Aug '20

21 Aug '20

I know that a frozen array doesn't have to be searched for elements in a younger generation, but how does it differ from an unfrozen array that hasn't been mutated since the last collection? David

3 3

Linking completely statically
by Volker Wysk 12 Aug '20

12 Aug '20

Hi! I know of the command line argument "-static". But this only affects the Haskell libraries. I want to link some programs completely statically, no external libraries needed. When just linking with "-static" I still have those dynamically linked things: desktop ~/bin $ ldd sicherung linux-vdso.so.1 (0x00007ffdab53f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3633da0000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3633d95000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3633d90000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3633d8a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3633d67000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3633ce3000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f3633cd7000) libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f3633ccb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3633ad9000) /lib64/ld-linux-x86-64.so.2 (0x00007f3633f0c000) Is it possible to link the remaining libraries statically too? Regards, Volker

6 9

Re: Linking completely statically
by Herrmann, Andreas 11 Aug '20

11 Aug '20

Hi Volker, > Is it possible to link the remaining libraries statically too? > Yes, it is possible to generate fully statically linked Haskell binaries. Though it requires a bit of setup. For example the GNU C library glibc is not really intended for fully static linking, but you can use musl as an alternative libc instead. Probably the easiest way is to use static-haskell-nix [1]. Usage instructions are available in the project README. See [2] if you're not familiar with Nix. Recently, the Haskell extension to Bazel, rules_haskell, also gained the ability to generate fully statically linked binaries building on top of Nix, see [3]. Best, Andreas [1]: https://github.com/nh2/static-haskell-nix [2]: https://nixos.org/ [3]: https://rules-haskell.readthedocs.io/en/latest/haskell-use-cases.html#build…

3 2

Re: Linking completely statically
by Volker Wysk 09 Aug '20

09 Aug '20

Am Sonntag, den 09.08.2020, 09:53 -0400 schrieb Brandon Allbery: > If you are obeying all the necessary restrictions on glibc, or you > are > using a different libc such as musl which is designed for static > linking, then "-Wl,-static" should be sufficient. Doing this with > glibc will likely result in a crash unless the same version of glibc > is available at runtime. Thanks for the tip! But I'll let it be for now. Cheers, Volker > > On 8/9/20, Volker Wysk <post(a)volker-wysk.de> wrote: > > Am Sonntag, den 09.08.2020, 08:59 -0400 schrieb Brandon Allbery: > > > Linux is not friendly to static linking, and you would need to > > > either > > > package or match exact versions of things like the nss and locale > > > libraries that are dynamically loaded at runtime and don't show > > > up in > > > ldd. This limitation comes from glibc and is documented in its > > > manual. > > > > That's bad. But, like you said, it *is* possible. The dar (disk > > archiver) program comes with a statically linked version > > "dar_static": > > > > % ldd dar_static > > Das Programm ist nicht dynamisch gelinkt > > > > ("The program isn't linked dynamically.") > > > > From your answer, I assume that this isn't supported by GHC. > > > > Cheers > > Volker > > > > > > > On Sun, Aug 9, 2020, 08:50 Volker Wysk <post(a)volker-wysk.de> > > > wrote: > > > > Hi! > > > > > > > > I know of the command line argument "-static". But this only > > > > affects > > > > the Haskell libraries. I want to link some programs completely > > > > statically, no external libraries needed. > > > > > > > > When just linking with "-static" I still have those dynamically > > > > linked > > > > things: > > > > > > > > desktop ~/bin $ ldd sicherung > > > > linux-vdso.so.1 (0x00007ffdab53f000) > > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 > > > > (0x00007f3633da0000) > > > > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 > > > > (0x00007f3633d95000) > > > > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 > > > > (0x00007f3633d90000) > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > > > > (0x00007f3633d8a000) > > > > libpthread.so.0 => /lib/x86_64-linux- > > > > gnu/libpthread.so.0 > > > > (0x00007f3633d67000) > > > > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 > > > > (0x00007f3633ce3000) > > > > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 > > > > (0x00007f3633cd7000) > > > > libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 > > > > (0x00007f3633ccb000) > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > > > (0x00007f3633ad9000) > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f3633f0c000) > > > > > > > > > > > > Is it possible to link the remaining libraries statically too? > > > > > > > > Regards, > > > > Volker > > > > _______________________________________________ > > > > Glasgow-haskell-users mailing list > > > > Glasgow-haskell-users(a)haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.10.2 released
by Ben Gamari 08 Aug '20

08 Aug '20

Hello all, The GHC team is happy to announce the release of GHC 8.10.2. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.2/ GHC 8.10.2 fixes a number of issues in present in GHC 8.10.1 including: * Fixes a bug in process creation on Windows (#17926). * Fixes a code generation bug resulting in incorrect code generation for foreign calls with complex arguments (#18527) * Fixes a bug causing object merging to fail when the lld linker is in use (#17962) * Introduces a workaround for a Linux kernel bug in the implementation of the timerfd mechanism (#18033). * Fixes a few specialiser regressions (#17810, #18120) as well introduces a variety of miscellaneous specialiser improvements (#16473, #17930, #17966) * Fixes a potential loss of sharing due to left operator sections (#18151). * Fix bootstrapping of GHC with the LLVM backend on x86-64 (#17920). * A few important correctness fixes for the low-latency garbage collector. Users of `--nonmoving-gc` are strongly encouraged to upgrade promptly. 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`. This situation will hopefully be improved for GHC 9.0.1 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

1 0

GHC formally discontinuing 32-bit Windows support?
by Ben Gamari 16 Jul '20

16 Jul '20

tl;dr. Unless someone speaks up, GHC will formally discontinue its (currently-broken) support for 32-bit Windows in 8.12. Hi everyone, As some have noticed, recent GHC releases' support for 32-bit Windows support can be generously described as "unreliable". This has been due to a combination of platform limitations, native toolchain bugs, and a general lack of capacity within the GHC community focusing on Windows support. I won't summarise the concrete issues here (see #17961, and #17700 for the current state-of-play) but let it suffice to say that we are currently stuck due to a bug in GNU binutils. However, I was recently informed that Cygwin and msys have recently discontinued their support for 32-bit Windows. While GHC uses a toolchain from the mingw32-w64 project, it seems only a matter of time before 32-bit builds cease there as well (see [1] for a summary of the relationships between these projects). Furthermore, Microsoft itself has said that 32-bit Windows 10 releases will cease later this year. All of this suggests to me that supporting 32-bit Windows in GHC will be, at best, an up-hill battle. Even worse, it is a battle with little to gained: essentially all Intel-based Windows systems today run on 64-bit-capable systems. I know of no compelling reasons why users would opt to use 32-bit Windows in 2020. Consequently, I suggest that we should formally discontinue 32-bit Windows support in GHC 8.12. In my opinion, GHC's limited engineering capacity on Windows is better spent elsewhere. However, if there are compelling reasons why some users still rely on 32-bit Windows support (despite it being largely unusable for the last two years), please do let me know. I have been consistently surprised by the number of users who have noted the absence of 32-bit Windows builds; I would love to know why they seem to be so popular. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/surviving-windows

1 0

[ANNOUNCE] GHC 8.8.4 is now available
by Ben Gamari 15 Jul '20

15 Jul '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.4 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.3: - Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately. - Works around a Linux kernel bug in the implementation of timerfd (#18033) - Fixes a few linking issues affecting ARM - Fixes "missing interface file" error triggered by some uses of Data.Ord.Ordering (#18185) - Fixes an integer overflow in the compact-normal-form import implementation (#16992) - `configure` now accepts a `--enable-numa` flag to enable/disable `numactl` support on Linux. - Fixes potentially lost sharing due to the desugaring of left operator sections (#18151). - Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024) As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.4-notes.h…

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released
by Ben Gamari 18 May '20

18 May '20

Hello all, The GHC team is happy to announce the availability of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1/ GHC 8.10.1 brings 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 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`. This situation will hopefully be improved for GHC 8.10.2 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

2 4

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 14 May '20

14 May '20

On Fri, 8 May 2020, Niklas Hambüchen wrote: > On 5/8/20 7:32 PM, Henning Thielemann wrote: > >> Can someone please give me examples where current state lacks > > * Currently stack traces are not printed, so users cannot forward them > to the developer, even if both the users and the developers would like > that. We are talking about the HasCallStack stack traces, yes? How is their emission addressed by extending exceptions with stack traces? > * Developers cannot easily produce stack traces do debug unintended > exceptions. What are "unintended exceptions"? What is an example of an "unintended exception"?

4 4

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 12 May '20

12 May '20

On Fri, 8 May 2020, Niklas Hambüchen wrote: > On 5/8/20 5:37 PM, Henning Thielemann wrote: > >> a callstack is not useful for a user. > > Call stacks have been very useful to me as a user of non-Haskell tools > so far, because they are excellent for attaching to bug reports and > usually led to developers fixing my problems faster. This confirms that they are not for you, but you only forward them to the developer. Can someone please give me examples where current state lacks and how they are addressed by the proposal(s)?

2 2