Will this be updated to the latest containers before release? It's two
versions behind at the moment.
On Mon, Sep 28, 2020, 3:14 PM Ben Gamari 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
> 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.
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
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 wrote:
> Hi Moritz,
>
>
>
>
Hi Moritz,
> However dlopen with musl on x86 seems fine.
Here's a dlopen example that segfaults if linked with -static:
#include
#include
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,
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
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
