[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:  new
        Priority:  highest           |            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):

 @carter, braindump as requested:

 * After reading @rwbarton's comment about a person wanting to pack up
 `dynlib`s for deployment in a single directory, I think I've changed my
 mind about installation layout. That is, I think the `install_name` of
 dynlibs should stay `@rpath/libname-x.y.z.dylib` as they are now.
 * This means that, upon installation, dynlibs should be copied to
 `$libdir/libname-x.y.z.dylib`, instead of the current
 `$libdir/libname-x.y.z/libname-x.y.z.dyblib`.
 * The `.hi` files should still be copied to the `$libdir/libname-x.y.z/`
 directory.
 * Perhaps the `a` static lib should also be copied to
 `$libdir/libname-x.y.z.ar`, for consistency with the `dynlib` dynamic lib.
 * Due to the use of `nub`, Cabal (in the case of `dynload deploy`) will
 then already make sure we only end up with a couple of `RPATH` equal to
 the `$libdir`s of the installed packages.
 * I'm not sure, but I think GHC also `nub`s the `RPATH`s (in the case of
 `dynload system`), this would have to be checked.
 * This plan doesn't involve mucking about with dynamic linking commands.

 So, if we go with the "put-all-the-dynlibs-in-single-directory" plan,
 which is what I now prefer, then we would need to do the following:

 * Add a `--libifacedir` setting to `Cabal`, which is, like `--libsubdir`
 implicitly prefixed by `$libdir`. `--libifacedir` determines where the
 `.hi` files go, and the default should be the same as `--libsubdir` (for
 all platforms)
 * Change the purpose of `--libsubdir` to mean the the location of the
 `.dylib`/`.so`/`.a` files.
 * For OSX only, change the default `libsubdir` to `.`, i.e. equal to
 `$libdir`.
 * Update `GHC`s Makefile, so that, on OS X, `make install` puts the
 `.dylib`/`.so`/`.a` in `$libdir`.

 Things that still need figuring out:
 * Do the above changes mean changes in the package database format? if so,
 what?
 * Do we need to update `stack` to use the new `--libifacedir` as well? or
 this it simply take over the default Cabal settings?

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