ghc-mod icon indicating copy to clipboard operation
ghc-mod copied to clipboard

Linker error with Nix, Stack and Template Haskell

Open tomsmalley opened this issue 8 years ago • 5 comments

This only occurs when TH is enabled in the module I'm trying to check. The project depends on wai-app-static but not optparse-applicative. This module does not import it. cabal new-repl works as expected.

[nix-shell:~/projects/semantic-reflex/semantic-reflex/src/Reflex/Dom/SemanticUI]$ ghc-mod check Lenses.hs --verbose debug
info: Found Stack project at: /etc/home/tom/projects/semantic-reflex/semantic-reflex
info: Using Stack project at: /etc/home/tom/projects/semantic-reflex/semantic-reflex
DEBUG: reading cache: /etc/home/tom/projects/semantic-reflex/semantic-reflex/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/setup-config.ghc-mod.cabal-components
DEBUG: resolveEntrypoint:
       ["-i","-i.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build","-isrc","-i.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build","-optP-D_GHCJS_","-optP-DGHCJS_GC_INTERVAL=60000","-optP-DGHCJS_BROWSER","-optP-include","-optP.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen/cabal_macros.h"]
DEBUG: resolveEntrypoint:
       ["-i","-i.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/test/test-tmp","-itest","-i.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/test/test-tmp","-optP-include","-optP.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen/cabal_macros.h"]
DEBUG: resolveEntrypoint:
       ["-i","-i.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/bench/bench-tmp","-ibench","-i.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/autogen","-I.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/bench/bench-tmp","-optP-include","-optP.stack-work/dist/x86_64-linux/Cabal-1.24.2.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.24.2.0/setup-config.ghc-mod.resolved-components
DEBUG: initSession: Session not initialized, creating new one
DEBUG: loadTargets: Loading: src/Reflex/Dom/SemanticUI/Lenses.hs
info: loadTargets:
      Target needs interpeter, switching to LinkInMemory/HscInterpreted. Perfectly normal if anything is using TemplateHaskell, QuasiQuotes or PatternSynonyms.
<command line>: can't load .so/.DLL for: /nix/store/vh2vpnc65r7cd2viip4fsad11mq7yj2l-wai-app-static-3.1.6.1/lib/ghc-8.0.2/x86_64-linux-ghc-8.0.2/libHSwai-app-static-3.1.6.1-JOHjWx1ETz87tV2XvseO6M-ghc8.0.2.so (/nix/store/vh2vpnc65r7cd2viip4fsad11mq7yj2l-wai-app-static-3.1.6.1/lib/ghc-8.0.2/x86_64-linux-ghc-8.0.2/libHSwai-app-static-3.1.6.1-JOHjWx1ETz87tV2XvseO6M-ghc8.0.2.so: undefined symbol: optparsezmapplicativezm0zi13zi2zi0zmEqIYOWOFTvf23sT5QTYn9U_OptionsziApplicativeziTypes_manyMzuzdcfmap_info)

tomsmalley avatar Oct 25 '17 08:10 tomsmalley

Sounds unlikely to be a ghc-mod problem TBH. ~~Have you checked the referenced file actually exists and has proper permissions and whatnot?~~

Edit: Nevermind didn't see the linker error. I would just try to rebuild everything. Can you try to compile the same package with cabal sandboxes instead of nix maybe?

DanielG avatar Oct 26 '17 00:10 DanielG

I think it is related to #905, just using a sandbox fixes it. nix-shell provides cabal-install 2.0.0.0 and gives the same error as in the linked issue.

tomsmalley avatar Oct 26 '17 11:10 tomsmalley

Actually looking at this issue again I seem to have missed you're using nix and stack together (dunno how, it says like right there ;) it seems strange to me that ghc would be complaining about linking a lib from nix when you're using stack. Does stack have some special support for nix where it uses packages from nix or something?

Either way could you tell me how to reproduce your nix environment on my machine? I don't actually use nix though but I happen to have it installed so be gentile :)

DanielG avatar Nov 07 '17 12:11 DanielG

the problem occurs when system and Nix glibc versions mismatch. In particular, v2.26 system and v2.30 in Nix will cause this error on every template haskell usage.

danbst avatar Mar 15 '20 16:03 danbst

I've solved this issue by using

system-ghc: true
install-ghc: false
skip-ghc-check: true

in stack.yaml and running everything from within nix-shell.

danbst avatar Mar 15 '20 17:03 danbst