[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:                    |             Blocking:
 Related Tickets:  #10458 #5289      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by trommler):

 #10458 has nothing to do with this issue. In #10458 we would like to
 access a function in a C library specified on the command line.

 In this ticket GHCi's linker fails to find a shared library that is
 required by another Haskell package, because the library is installed in a
 path that is not searched by the operating system's runtime linker. As a
 workaround you could add the path of `libz.so` to `LD_LIBRARY_PATH`.

 Suppose, you only want to use Haskell zlib in you Main module, I think
 GHCi's linker should not try to load `libz.so` at all and merely load the
 Haskell package's shared library (`libHSzlib<...>.so`). The Haskell shared
 library contains the appropriate DT_RUNPATH tag pointing to the location
 of the C library and so it is found and loaded.

 On ELF systems I would say the fix is to teach `Linker.hs` to not load
 dependent libraries but rely on the system linker to do the Right Thing.
 On OS X there are issues with symbols from dependent libraries not being
 reexported by default.

 I could look into this once I am done with #10458, but I would rather like
 to see a document specifying the expected behavior of the GHCi linker and
 then reimplement it. We also need regression tests for all those special
 cases! I agree with Austin. The amount of patches starts to smell.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11042#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler