<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div> Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 7:45 PM Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Sep 2020 at 7:18 PM, Cheng Shao <<a href="mailto:cheng.shao@tweag.io" target="_blank">cheng.shao@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Moritz,<br><br><br><br>> However dlopen with musl on x86 seems fine.<br><br><br><br>Here's a dlopen example that segfaults if linked with -static:<br><br><br><br>#include <stdio.h><br><br>#include <dlfcn.h><br><br><br><br>int main() {<br><br> void *h = dlopen("/usr/lib/libsqlite3.so", RTLD_NOW);<br><br> char *f = dlsym(h, "sqlite3_version");<br><br> printf("%s\n", f);<br><br> return 0;<br><br>}<br><br><br><br>On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann<br><br><<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:<br><br>><br><br>> 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...<br><br>><br><br>> On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <<a href="mailto:cheng.shao@tweag.io" target="_blank">cheng.shao@tweag.io</a>> wrote:<br><br>>><br><br>>> Hi Ben,<br><br>>><br><br>>><br><br>>><br><br>>> > We will likely transition the Alpine binary distribution to be fully<br><br>>><br><br>>> statically-linked, providing a convenient, distribution-independent<br><br>>><br><br>>> packaging option for Linux users.<br><br>>><br><br>>><br><br>>><br><br>>> iirc for statically linked executables, musl doesn't even support<br><br>>><br><br>>> dlopen, so wouldn't this mean such a bindist would fail for all<br><br>>><br><br>>> LoadDLL ghci commands?<br><br>>><br><br>>><br><br>>><br><br>>> Cheers,<br><br>>><br><br>>> Cheng<br><br>>><br><br>>><br><br>>><br><br>>> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>> wrote:<br><br>>><br><br>>> ><br><br>>><br><br>>> > Hello all,<br><br>>><br><br>>> ><br><br>>><br><br>>> > The GHC team is very pleased to announce the availability of the first<br><br>>><br><br>>> > alpha release in the GHC 9.0 series. Source and binary distributions are<br><br>>><br><br>>> > available at the usual place:<br><br>>><br><br>>> ><br><br>>><br><br>>> > <a href="https://downloads.haskell.org/ghc/9.0.1-alpha1/" rel="noreferrer" target="_blank">https://downloads.haskell.org/ghc/9.0.1-alpha1/</a><br><br>>><br><br>>> ><br><br>>><br><br>>> > This first alpha comes quite a bit later than expected. However, we have<br><br>>><br><br>>> > done a significant amount of testing on this pre-release and therefore<br><br>>><br><br>>> > hope to be able to move forward quickly with a release candidate next<br><br>>><br><br>>> > week and with a final release in mid-October.<br><br>>><br><br>>> ><br><br>>><br><br>>> > GHC 9.0.1 will bring a number of new features:<br><br>>><br><br>>> ><br><br>>><br><br>>> > * A first cut of the new LinearTypes language extension [1], allowing<br><br>>><br><br>>> > use of linear function syntax and linear record fields.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * A new bignum library (ghc-bignum), allowing GHC to be more easily<br><br>>><br><br>>> > used with integer libraries other than GMP.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * Improvements in code generation, resulting in considerable<br><br>>><br><br>>> > performance improvements in some programs.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * Improvements in pattern-match checking, allowing more precise<br><br>>><br><br>>> > detection of redundant cases and reduced compilation time.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * Implementation of the "simplified subsumption" proposal [2]<br><br>>><br><br>>> > simplifying the type system and paving the way for QuickLook<br><br>>><br><br>>> > impredicativity in GHC 9.2.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * Implementation of the QualifiedDo extension [3], allowing more<br><br>>><br><br>>> > convenient overloading of `do` syntax.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * Improvements in compilation time.<br><br>>><br><br>>> ><br><br>>><br><br>>> > And many more. See the release notes [4] for a full accounting of the<br><br>>><br><br>>> > changes in this release.<br><br>>><br><br>>> ><br><br>>><br><br>>> > Do note that there are a few things that we expect will change before<br><br>>><br><br>>> > the final release:<br><br>>><br><br>>> ><br><br>>><br><br>>> > * We expect to sort out a notarization workflow for Apple Darwin,<br><br>>><br><br>>> > allowing our binary distributions to be used on macOS Catalina<br><br>>><br><br>>> > without hassle.<br><br>>><br><br>>> ><br><br>>><br><br>>> > Until this has been sorted out Catalina users can exempt the<br><br>>><br><br>>> > current macOS binary distribution from the notarization requirement<br><br>>><br><br>>> > themselves by running `xattr -cr .` on the unpacked tree before<br><br>>><br><br>>> > running `make install`.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * We will likely transition the Alpine binary distribution to be fully<br><br>>><br><br>>> > statically-linked, providing a convenient, distribution-independent<br><br>>><br><br>>> > packaging option for Linux users.<br><br>>><br><br>>> ><br><br>>><br><br>>> > * We will be merging a robust solution for #17760 which will introduce<br><br>>><br><br>>> > a new primitive, `keepAlive#`, to the `base` library, subsuming<br><br>>><br><br>>> > most uses of `touch#`.<br><br>>><br><br>>> ><br><br>>><br><br>>> > As always, do test this release and open tickets for whatever issues you<br><br>>><br><br>>> > encounter. To help with this, we will be publishing a blog post<br><br>>><br><br>>> > describing use of our new `head.hackage` infrastructure to ease testing<br><br>>><br><br>>> > of larger projects with Hackage dependencies later this week.<br><br>>><br><br>>> ><br><br>>><br><br>>> > Cheers,<br><br>>><br><br>>> ><br><br>>><br><br>>> > - Ben<br><br>>><br><br>>> ><br><br>>><br><br>>> ><br><br>>><br><br>>> > [1] <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst</a><br><br>>><br><br>>> > [2] <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst</a><br><br>>><br><br>>> > [3] <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst</a><br><br>>><br><br>>> > [4] <a href="https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html" rel="noreferrer" target="_blank">https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html</a><br><br>>><br><br>>> > _______________________________________________<br><br>>><br><br>>> > ghc-devs mailing list<br><br>>><br><br>>> > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br><br>>><br><br>>> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br><br>>><br><br>>> _______________________________________________<br><br>>><br><br>>> ghc-devs mailing list<br><br>>><br><br>>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br><br>>><br><br>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br><br>>><br><br></blockquote></div></div>
</blockquote></div>