#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