> that I know we have musl (x86_64, aarch64) based ghcs in production.
These ghc bindists (at least the one produced on gitlab ci) have
dynamically linked ghc executables iirc. Last time I tried to turn off
DYNAMIC_GHC_PROGRAM when building ghc on alpine, the produced ghc will
panic on TH code. That's on the 8.8 branch though.
On Tue, Sep 29, 2020 at 4:21 PM Moritz Angermann
<moritz.angerm...@gmail.com> wrote:
>
> 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.angerm...@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.s...@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.angerm...@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.s...@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 <b...@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@haskell.org
>>>
>>> >>
>>>
>>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>> >>
>>>
>>> >> _______________________________________________
>>>
>>> >>
>>>
>>> >> ghc-devs mailing list
>>>
>>> >>
>>>
>>> >> ghc-devs@haskell.org
>>>
>>> >>
>>>
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>> >>
>>>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
