<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class="">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 <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388" class="">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388</a> — maybe reading through that or the plan I outlined at <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/3372" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/3372</a> might help, though I’m not sure.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">I realise this isn’t much help, but maybe it points you in a direction where you can begin to understand some more.</div><div class=""><br class=""></div><div class="">Julian</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő <<a href="mailto:gergo@erdi.hu" class="">gergo@erdi.hu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">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.<br class=""><br class="">The details are at <a href="https://github.com/clash-lang/clash-compiler/issues/1686" class="">https://github.com/clash-lang/clash-compiler/issues/1686</a><br class="">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.<br class=""><br class="">So, does this ring a bell for anyone?<br class=""><br class="">Thanks,<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Gergo<br class="">_______________________________________________<br class="">ghc-devs mailing list<br class=""><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></div></div></blockquote></div><br class=""></div></body></html>