What changed between GHC 8.8 and 8.10 that could cause this?
julian at leviston.net
Thu Mar 4 12:42:20 UTC 2021
I don’t know enough about what Clash does to comment really, but it sounds like it’s to do with my work on enabling multiple linker instances in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388> — maybe reading through that or the plan I outlined at https://gitlab.haskell.org/ghc/ghc/-/issues/3372 <https://gitlab.haskell.org/ghc/ghc/-/issues/3372> might help, though I’m not sure.
Strange, though, as this work was to isolate state in GHC — to change it from using a global IORef to use a per-process MVar . But it definitely did change the way state is handled, so it might be the related to these issues somehow?
I realise this isn’t much help, but maybe it points you in a direction where you can begin to understand some more.
> On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő <gergo at erdi.hu> wrote:
> I'm trying to figure out a Clash problem and managed to track it down to a GHC upgrade; specifically, a given Clash version, when based on GHC 8.8, has no problem synthesizing one module after another from one process; but the same Clash version with GHC 8.10 fails with link-time errors on the second compilation.
> The details are at https://github.com/clash-lang/clash-compiler/issues/1686
> but for now I'm just hoping that some lightbulb will go off for someone if some handling of internal state has changed in GHC that could mean that the symbol tables of loaded modules could persist between GHC invocations from the same process.
> So, does this ring a bell for anyone?
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs