Hey Facundo: can you share a link to the underlying error ? I tried to find the error output in the linked ticket, but I only see a failure message at the stack_build_tool level. Rather than a ghc or linker error
How would I replicate the build failure locally? Would cabal get haskellR ; cd haskelR* ; cabal build ; cabal test suffice ? On Tue, Nov 16, 2021 at 9:27 AM Domínguez, Facundo < facundo.doming...@tweag.io> wrote: > Dear devs, > > I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving > differently than previous compilers when running Template Haskell code. > > When upgrading HaskellR to use a newer ghc I found that it would work fine > with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R > runtime in particular, is sensitive to local state in the threads that are > used to execute the runtime. HaskellR is arranging to run the R runtime > when running TemplateHaskell splices, and this stopped working in MacOS > with ghc-8.10.6. > > The error I got is not new. It comes from R and we would get it in ghci if > we try to use HaskellR without passing the command line flag > -fno-ghci-sandbox. But this is the first time we get the error when using > TemplateHaskell. > > Does anyone know if there have been changes to the threads in which the TH > splices are run? And were there any changes specific to TH in MacOS? > > Thanks in advance, > Facundo > > [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170 > _______________________________________________ > 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
