Very late followup, but I just wanted to share that Fedora users can
install this now (stable since last week) with:
sudo dnf module install ghc:9.0/default
Thanks, Jens
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailm
George Colpitts writes:
> Hi Ben,
>
> What are the current plans / schedule for 9.0.1?
>
Hi George,
At the moment things are blocked on a solution to #17760, which I am
currently in the process of working through. There have been several
false-starts on this ticket and while the solution we are
Hi Ben,
What are the current plans / schedule for 9.0.1?
Thanks
George
On Mon, Sep 28, 2020 at 4: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 distributions are
> availab
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 d
> 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. Th
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
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, S
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 bindist
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. How
11 matches
Mail list logo
