We did some investigation last night in IRC and came to the conclusion
#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]: 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