#12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): Given that I'm the one who wrote GHC's {{{@rpath}}}-relative {{{install_name}}} code, and Cabal's {{{RPATH}}}-handling code, I want to point out one problem that needs some thought before we make all the {{{install_name}}}s {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}: sometimes, the libraries that we link against aren't in their installed location yet. And there is one particular case when this is a problem: when a Cabal {{{testsuite}}} executable is dynamically linked against the library under development. In this case, the {{{libname-x.y.z.dylib}}} is still in {{{./dist/build}}}. Now, because (currently) the {{{install_name}}} is simply {{{@rpath/libname-x.y.z.dylib}}}, we can simply execute the {{{testsuite}}} executable where the {{{DYLD_LIBRARY_PATH}}} contains {{{./dist/build}}}. If the {{{install_name}}} is going to be changed to {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}[1], then we have to take care of the above-mentioned problem. [1] Another solution is of course to put (or symlink) all the {{{.dylib}}}s in the {{{$lib}}} directory instead of {{{$lib/libname-x.y.z}}}, which I've seen being suggested, but is something I personally don't like it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12479#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler