[GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs

[GHC]

#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]:
 > This seems fairly bad and shouldn't block forever on a redesign if
 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