[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 chak):

 Replying to [comment:13 rwbarton]:
 > We did some investigation last night in IRC and came to the conclusion
 that the runtime loader in Sierra has a new limit on the `sizeofcmds`
 field which is the total size of all the load commands in the dynamic
 library. Looking at the `otool -l` output in an earlier attachment, we can
 see that the main contributors to the size are primarily the RPATH entries
 and to a lesser extent the LOAD_DYLIB entries. There are over 100 of each,
 and the paths in the RPATH entries are quite long (I guess this is why
 stack is affected in particular).
 >
 > So, I don't expect that disabling split objects will help at all,
 unfortunately. There seems to just be a limit on the total size of RPATH
 entries we can use.
 >
 > In fact Cabal is the one choosing these RPATHs, not GHC itself. So this
 will require some kind of change to Cabal to decrease the total size of
 the RPATH entries it produces.

 I suspect that this particular use of RPATHs is a remnant of trying to
 deal with dylibs on macOS as its done on Linux. On macOS, there is a
 pretty simple fix to this (which is what I use in Haskell for Mac btw).
 The library name of a dylib in macOS can include a path component. So,
 instead of just using the filename of a library by itself as its install
 name, simply use the filename '''prefixed''' by the package directory. So,
 instead of `base-x.y.z-ABCD.dylib` use `base-x.y.z/base-x.y.z-ABCD.dylib`.

 Then, only one RPATH is needed, namely the GHC LIBDIR (or wherever the
 package db is). This keeps the load command size down and solves the
 problem in #11587.

 (Incidentally, this approach in combination with using `@loader_path` in
 RPATH specs also allows to make relocate package dbs, which is important
 if you want to ship a macOS app that includes dynamically linked Haskell
 code.)

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