- Glasgow-haskell-users

Language extension histories
by David Feuer 01 Nov '20

01 Nov '20

I'm working on some code I want to be compatible with multiple GHC versions and I'm trying to figure out which language extensions I can reasonably use. I definitely need usable fancy pattern synonyms (not the bare-bones ones in 7.8). So that should set a lower bound, but I don't remember where. 7.10? 8.0? I'd also *like* to use an injective type family, but I can work around that pretty easily with a data family if necessary. When did PatternSynonyms and TypeFamilyDependencies each become reasonably usable?

3 4

"... causes overflow in R_X86_... relocation"
by Volker Wysk 17 Oct '20

17 Oct '20

Hi. I have a litte program named "svumb", which compiles and links without error or warning message. But when I start it, this happens: build/svumb: Symbol `qtahzmqt5zm0zi7zi0zm4ATcbzzMngNWCbnemaqWUdM_GraphicsziUIziQtahziGeneratedziWidgetsziQMessageBox_setText_closure' causes overflow in R_X86_64_32 relocation (... long list of similar messages ...) build/svumb: Symbol `stg_INTLIKE_closure' causes overflow in R_X86_64_32 relocation build/svumb: error while loading shared libraries: unexpected reloc type 0x0b Do those messages make sense to anyone? What is a "R_X86_64_32 relocation"? What is a "reloc type"? What's happening?? Calling "sudo ldconfig" doesn't help. The program uses the Qtah package, which is a Qt binding for Haskell. It might have something to do with this. It can't be linked statically, because then the following error occurs after starting the compiled and linked program: .../build/svumb: error while loading shared libraries: libqtah.so.0: cannot open shared object file: No such file or directory Compiling it dynamically had worked, but now I have the problem above. Regards, Volker

2 2

Exchange "ar" prefix in ghc build
by Marius Melzer 14 Sep '20

14 Sep '20

Hi, I'm trying to add L4Re as a new OS to GHC and I'm already struggling a bit with the setup. I added l4re to a few places that seem to make sense (in aclocal.m4:296/2165, in config.sub:1371, in compiler/GHC/Platform.hs:132 and in libraries/ghc-boot/GHC/Platform/ArchOS.hs:99/156). Now I wanted to try to build it to see where it fails to continue, but I'm failing on the configure step, I have so far: ./configure --target=aarch64-unknown-l4re CC=aarch64-linux-gnu-gcc Which fails when it looks for ar (with the prefix aarch64-unknown-l4re instead of aarch64-linux-gnu): checking for aarch64-unknown-l4re-ar... no configure: error: cannot find ar in your PATH, no idea how to make a library Can I somehow tell configure to use the aarch64-linux-gnu prefix for ALL tools (nm, ar, gcc, etc.) even though I build for aarch64-unknown-l4re? Or if not, is there a way to set the ar tool in the same way as I did for gcc with CC=...? Thanks in advance, Marius

1 0

Does newByteArray clear?
by David Feuer 27 Aug '20

27 Aug '20

I'm looking to play around with an array-based structure with sub-linear worst-case bounds. Array is pretty awkward in that context because creating a new one takes O(n) time to initialize it. Is that all true of newByteArray, or can I get one with arbitrary garbage in it for cheap?

3 3

Haskell Implementors' Workshop lightning talks
by Ben Gamari 24 Aug '20

24 Aug '20

Hello everyone, The Haskell Implementors' Workshop will be held this Friday, August 28th, colocated with virtual ICFP. As usual, we will have a number of slots for lightning-talks. These are five-minute-long talks where you can present libraries, language extension ideas, plugins, tools... anything that the Haskell implementor community might find interesting. We are collecting talk submissions via Google Forms [1] and will notify speakers of their slots on August 27th. We are looking forward to seeing you there! Cheers, - Ben [1] https://forms.gle/a8sZQNRRMe9H9YnX8

1 0

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