This seems fairly bad and shouldn't block forever on a redesign if
#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:10 rwbarton]: there's a way to fix it in the short term.
However, I don't understand the issue precisely. The ticket title has a
kind of type error, since `extra-lib-dirs` is a flag that is only meaningful to Cabal, not to ghc. Could someone provide a reproducer that does not involve stack or Cabal, or characterize the interaction between Cabal and ghc? Let me describe the issue and perhaps you could help me turn this into a regression test: 1. We have a Haskell package that calls out to a C library. In this ticket the zlib package calls the C library `libz.so`. 1. We want to compile a module that depends on the Haskell package (from 1) and also uses Template Haskell. 1. To compile the module Template Haskell loads all packages that are specified as dependencies (in the Cabal file or on the ghc command line). Currently this means loading all transitive dependencies of each package to be loaded. Package loading fails because `libz.so` cannot be found in any standard directory because on the system @mboes describes it is installed elsewhere. The title of the ticket suggests to specify the directory where `libz.so` is located in the cabal file (of the package using zlib). I think this would violate abstraction: As a client of package zlib I expect zlib to be self-contained and provide all information that is needed to use it. In fact for a dynamically linked zlib package that is indeed the case. When building a dynamically linked package we record an R(UN)PATH for C libraries that are not installed in standard locations. If we just loaded the shared library of package zlib (`libHSzlib<...>.so` we would not need to know where to find `libz.so` because the system runtime loader takes care of that. But currently GHC's dynamic linker mimics the behavior of the (static) RTS linker and would load `libz.so` before it loads `libHSzlib<...>.so`. I could extract a patch from my work on #11238 that implements what I said in the third paragraph of comment:6. It would not only be a short term fix but also be a step in the right direction. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11042#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler