[GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4

[GHC]

#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