[ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released

Tue Sep 29 14:21:18 UTC 2020

This sent me down an interesting path.  You are right that dlopen on
returns NULL with musl on x86_64, and dlerror will subsequently produce
"Dynamic loading not supported" if asked to compile with -static.  I think
GHC has code to fallback to archives in the case where loading
shared objects fails, but I can't find the code right now.  It still means
you'd need to have static sqlite (in this case) and other libraries around.

I'm still a bit puzzled, and I think I'm missing something.  It remains,
that I know we have musl (x86_64, aarch64) based ghcs in production.  I
wonder if there is something we got right by accident, that makes this work
smoothly for us.  Warrants more investigation.

Cheers,
 Moritz

On Tue, Sep 29, 2020 at 7:45 PM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Happy to give this a try later today. Been using fully static musl builds
> (including cross compilation) for x86_64 for a while now; and did not
> (yet?) run into that SQLite issue. But did have it use shared objects in
> iserv.
>
> On Tue, 29 Sep 2020 at 7:18 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>
>> Hi Moritz,
>>
>>
>>
>> > However dlopen with musl on x86 seems fine.
>>
>>
>>
>> Here's a dlopen example that segfaults if linked with -static:
>>
>>
>>
>> #include <stdio.h>
>>
>> #include <dlfcn.h>
>>
>>
>>
>> int main() {
>>
>>   void *h = dlopen("/usr/lib/libsqlite3.so", RTLD_NOW);
>>
>>   char *f = dlsym(h, "sqlite3_version");
>>
>>   printf("%s\n", f);
>>
>>   return 0;
>>
>> }
>>
>>
>>
>> On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann
>>
>> <moritz.angermann at gmail.com> wrote:
>>
>> >
>>
>> > No. Not necessarily. We can perfectly fine load archives and the
>> pre-linked ghci objects. However dlopen with musl on x86 seems fine. On arm
>> it’s not implemented, and just throws an error message. There is a -dynamic
>> flag in HEAD, which disables GHC even trying to load dynamic libraries and
>> always assuming there is no dynamic linking facility, even if configure
>> reports the existence of dlopen...
>>
>> >
>>
>> > On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>>
>> >>
>>
>> >> Hi Ben,
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> > We will likely transition the Alpine binary distribution to be fully
>>
>> >>
>>
>> >>    statically-linked, providing a convenient, distribution-independent
>>
>> >>
>>
>> >>    packaging option for Linux users.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> iirc for statically linked executables, musl doesn't even support
>>
>> >>
>>
>> >> dlopen, so wouldn't this mean such a bindist would fail for all
>>
>> >>
>>
>> >> LoadDLL ghci commands?
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Cheers,
>>
>> >>
>>
>> >> Cheng
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Hello all,
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > The GHC team is very pleased to announce the availability of the
>> first
>>
>> >>
>>
>> >> > alpha release in the GHC 9.0 series. Source and binary distributions
>> are
>>
>> >>
>>
>> >> > available at the usual place:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > This first alpha comes quite a bit later than expected. However, we
>> have
>>
>> >>
>>
>> >> > done a significant amount of testing on this pre-release and
>> therefore
>>
>> >>
>>
>> >> > hope to be able to move forward quickly with a release candidate next
>>
>> >>
>>
>> >> > week and with a final release in mid-October.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > GHC 9.0.1 will bring a number of new features:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * A first cut of the new LinearTypes language extension [1],
>> allowing
>>
>> >>
>>
>> >> >    use of linear function syntax and linear record fields.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * A new bignum library (ghc-bignum), allowing GHC to be more easily
>>
>> >>
>>
>> >> >    used with integer libraries other than GMP.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Improvements in code generation, resulting in considerable
>>
>> >>
>>
>> >> >    performance improvements in some programs.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Improvements in pattern-match checking, allowing more precise
>>
>> >>
>>
>> >> >    detection of redundant cases and reduced compilation time.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Implementation of the "simplified subsumption" proposal [2]
>>
>> >>
>>
>> >> >    simplifying the type system and paving the way for QuickLook
>>
>> >>
>>
>> >> >    impredicativity in GHC 9.2.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Implementation of the QualifiedDo extension [3], allowing more
>>
>> >>
>>
>> >> >    convenient overloading of `do` syntax.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Improvements in compilation time.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > And many more. See the release notes [4] for a full accounting of the
>>
>> >>
>>
>> >> > changes in this release.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Do note that there are a few things that we expect will change before
>>
>> >>
>>
>> >> > the final release:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * We expect to sort out a notarization workflow for Apple Darwin,
>>
>> >>
>>
>> >> >    allowing our binary distributions to be used on macOS Catalina
>>
>> >>
>>
>> >> >    without hassle.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >    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`.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * We will likely transition the Alpine binary distribution to be
>> fully
>>
>> >>
>>
>> >> >    statically-linked, providing a convenient,
>> distribution-independent
>>
>> >>
>>
>> >> >    packaging option for Linux users.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * We will be merging a robust solution for #17760 which will
>> introduce
>>
>> >>
>>
>> >> >    a new primitive, `keepAlive#`, to the `base` library, subsuming
>>
>> >>
>>
>> >> >    most uses of `touch#`.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > As always, do test this release and open tickets for whatever issues
>> you
>>
>> >>
>>
>> >> > encounter. To help with this, we will be publishing a blog post
>>
>> >>
>>
>> >> > describing use of our new `head.hackage` infrastructure to ease
>> testing
>>
>> >>
>>
>> >> > of larger projects with Hackage dependencies later this week.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Cheers,
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > - Ben
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > [1]
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
>>
>> >>
>>
>> >> > [2]
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
>>
>> >>
>>
>> >> > [3]
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
>>
>> >>
>>
>> >> > [4]
>> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
>>
>> >>
>>
>> >> > _______________________________________________
>>
>> >>
>>
>> >> > ghc-devs mailing list
>>
>> >>
>>
>> >> > ghc-devs at haskell.org
>>
>> >>
>>
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> >>
>>
>> >> _______________________________________________
>>
>> >>
>>
>> >> ghc-devs mailing list
>>
>> >>
>>
>> >> ghc-devs at haskell.org
>>
>> >>
>>
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> >>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200929/3b36f5f2/attachment.html>