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