Hi,
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 — maybe reading through that or the plan I outlined at 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.

Julian

On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő <gergo@erdi.hu> wrote:

Hi,

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?

Thanks,
Gergo
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs