#11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x ---------------------------------+-------------------------------------- Reporter: borsboom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8266, #8721 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by darchon): TL;DR @thomie: After some consideration, I agree with the "wontfix". I know of one "valid" reason to set the (DY)LD_LIBRARY_PATH environment variable in a "standard" Haskell development environment, and that is when there are dynamically-linked executables in a testing situation (i.e. a dynamically linked executable created by {{{cabal test}}}). This is based on what I said here: https://github.com/haskell/cabal/issues/2330#issuecomment-69201669 As of Cabal-1.22, Cabal sets all the RPATHs instead of letting GHC handle them. What Cabal does differently from GHC, is that it sets the RPATHs to the final install locations, not the directory where the library currently resides. Now, for installed libraries, the final install location and the directory where the library currently resides are one and the same; however, for a library under development, the final install location is very must likely different from the place it currently resides: {{{./dist/build}}}. So, since a dynamically-linked executable created by {{{cabal test}}} is created the same way as any other dynamically-linked executable, I had to find a way for the created test executable to find the library under development. The way I did this is have {{{cabal test}}} run the test executable in an environment where (DY)LD_LIBRARY_PATH includes {{{.dist/build}}}: https://github.com/haskell/cabal/blob/6357bc536f993542fc385e3d1a59dac5f8b612... However, since I don't see how the dynamically linked testing executables can end up in one of the protected system locations, their (DY)LD_LIBRARY_PATH environment variables will not be stripped. Consequently, this one "valid" use of (DY)LD_LIBRARY_PATH is not affected by OS X's behaviour. So for now, I agree with the "wontfix", unless someone can truly point out another valid reason to set (DY)LD_LIBRARY_PATH. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11617#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler