search

DanielG / ghc-mod

Happy Haskell Hacking for editors. DEPRECATED
Other
677 stars 175 forks source link

ghc-mod fails with unknown symbol store_load_barrier in atomic-primops #746

Open wraithm opened 8 years ago

wraithm commented 8 years ago

I'm using stack for my project, and I noticed that ghc-mod was failing with cannot determine type when I tried to query the types of expressions in Emacs. So, I tried to just run ghc-mod on the command-line, and I found that in files where type-queries were failing, I would get this same output.

$ cd myproject
$ ghc-mod check src/Path/To/Haskell/File.hs
ghc-mod: /home/matt/.stack/snapshots/x86_64-linux/lts-5.2/7.10.3/lib/x86_64-linux-ghc-7.10.3/atomic-primops-0.8.0.2-Il4AcfudM89CXhIIq1LN3T/libHSatomic-primops-0.8.0.2-Il4AcfudM89CXhIIq1LN3T.a: unknown symbol `store_load_barrier'
unable to load package `atomic-primops-0.8.0.2'

This output doesn't happen for every file, but it does for many. I can't really tell if there's a pattern of any sort in the source code where this occurs.

I installed ghc-mod via stackage LTS-5.2.

dpwiz commented 8 years ago

Oh, I'm getting this too.

wraithm commented 8 years ago

I'm on ghc-mod 5.5.0.0 with GHC 7.10.3

I have somewhat of a sneaking suspicion that this only happens in files where atomic-primops is somewhere in the dependencies. This doesn't seem to affect modules in my project that are simpler. I cannot confirm this theory for sure.

dpwiz commented 8 years ago

I've got unagi-chan in project deps which depends on it. But a freshly created project and the primops repo itself checked just fine. I've tried removing .stack-work and ~/.stack to no avail.

wraithm commented 8 years ago

Same.

Also, my project does not have atomic-primops as an explicit dep. I also use unagi-chan in my project. Though, I get this error even in a package that doesn't explicitly depend on unagi-chan. It depends on another package which uses unagi-chan, and I'm importing modules from that package which use unagi-chan under the hood.

dpwiz commented 8 years ago

I've started with a blank project and everything you need to get a nice crash is:

1) Add atomic-primops to deps. 2) Turn on TH extension in cabal or module being checked. 3) Run ghc-mod with debug output enabled 4) :boom:

Target needs interpeter, switching to LinkInMemory/HscInterpreted. Perfectly normal if anything is using TemplateHaskell, QuasiQuotes or PatternSynonyms.

$ ghc-mod --verbose debug check src/Main.hs
DEBUG: reading cache: /home/wiz/src/crap/atomic-oops/.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/setup-config.ghc-mod.cabal-components
DEBUG: resolveEntrypoint:
       ["-i","-i.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/atomic-oops/atomic-oops-tmp","-isrc","-i.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/atomic-oops/atomic-oops-tmp","-optP-include","-optP.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/autogen/cabal_macros.h"]
DEBUG: resolveEntrypoint: []
DEBUG: making sure autogen files exist
DEBUG: reading cache: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/setup-config.ghc-mod.resolved-components
DEBUG: initSession: Session not initialized, creating new one
DEBUG: loadTargets: Loading: src/Main.hs
info: loadTargets:
      Target needs interpeter, switching to LinkInMemory/HscInterpreted. Perfectly normal if anything is using TemplateHaskell, QuasiQuotes or PatternSynonyms.
ghc-mod: /home/wiz/.stack/snapshots/x86_64-linux/lts-5.2/7.10.3/lib/x86_64-linux-ghc-7.10.3/atomic-primops-0.8.0.2-Il4AcfudM89CXhIIq1LN3T/libHSatomic-primops-0.8.0.2-Il4AcfudM89CXhIIq1LN3T.a: unknown symbol `store_load_barrier'
unable to load package `atomic-primops-0.8.0.2'
wraithm commented 8 years ago

Well done

DanielG commented 8 years ago

I can indeed reproduce this :O

rm -rf foo; stack new foo; cd foo; sed -i 's/\(build-depends:.*\)/\1, atomic-primops/' foo.cabal; printf '{-# LANGUAGE TemplateHaskell #-}\nmain = return ()\n' > src/Lib.hs; ghc-mod check src/Lib.hs; cd ..
DanielG commented 8 years ago

Alright so in order to figure out if this is a bug in ghc-mod or in GHC itself we should construct a testcase using the GHC API directly, something along these lines: https://github.com/DanielG/ghc-mod/blob/master/test/manual/not-interpreted-error/GhcTestcase.hs.

ghc-mod debug will dump the ghc options being used for the stack project which can be passed to GHC via parseDynamicFlags. After that all that's needed are setTarget and load.

nlinker commented 8 years ago

I have it too, trying to get a minimal example to reproduce this.

nick@g55vw:~/haskell/vs$ ghc-mod check search-dump/Main.hs 
ghc-mod: /home/nick/.stack/snapshots/x86_64-linux/lts-4.0/7.10.3/lib/x86_64-linux-ghc-7.10.3/atomic-primops-0.8.0.2-Il4AcfudM89CXhIIq1LN3T/libHSatomic-primops-0.8.0.2-Il4AcfudM89CXhIIq1LN3T.a: unknown symbol `store_load_barrier'
unable to load package `atomic-primops-0.8.0.2'
$ uname -a
Linux g55vw 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux