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 <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. Julian > On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő <ge...@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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
