#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): That patch seems...odd to me. I think we might have a simpler problem: I did on nixos unstable (but I think 18.09 would also work) - clone recentish Cabal - `nix-shell -p 'haskellPackages.ghcWithPackages (p: [ p.zlib ])' -p zlib -p haskellPackages.happy -p haskellPackages.alex` - `new-configure -O0 --enable-tests --extra-lib- dirs=/nix/store/...-zlib-1.2.11/lib` - `cabal new-repl cabal-install` `-L` from `--extra-lib-dirs` did make it to ghci, but it fails with {{{ <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) }}} and `ghci -v` gives me {{{ *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.so *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name liblibz.so *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name z.lib *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.lib *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.dll.a *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name z.dll.a *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.a *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name z.a Loading package digest-0.0.1.2 ... *** Deleting temp files: Deleting: *** Deleting temp dirs: }}} There's plenty to minimize and control here (e.g. `~/.cabal/store/ghc-8.4.3/package.db` populated in different nix-shells), but I want to ask the simple check, if ghc is looking up libz.so, why isn't it using -L? (Maybe the directories listed in the package db override it?) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11042#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler