[GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects

[GHC]

#14444: Linker limit on OS X Sierra breaks builds for big projects
-------------------------------------+-------------------------------------
        Reporter:  dredozubov        |                Owner:  angerman
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
  (Linking)                          |
      Resolution:                    |             Keywords:
Operating System:  MacOS X           |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by aosivitz):

 So, I've recently run into this with a large project (using stack).

 I've tried to make a small reproduce case but have not succeeded. I
 generated a stack project that builds a library along with 400 dummy
 dependencies, each of which has a long package name. This is a larger
 number of dependencies than my original project, but it doesn't trigger
 the panic. So is there something else I need to do to cause this?

 Other funny things I've seen:
 Sometimes the build fails after `slack clean`, but then builds
 successfully after running it again. The big difference I see is that in
 the first case the link command is trying to build
 '/var/folders/.../ghc4371_0/libghc_100.dylib' when it fails, and in the
 second case it builds '.stack-work/.../libHSpanictest-0.0.0
 -8KaC2kNKjFj6cJfkbgZkev-ghc8.2.2.dylib' and succeeds. Is that just a quirk
 of stack or would it be a meaningful difference? What does it mean to
 build 'libghc_X.dylib'?

 I apologize if this info is too stack specific, but it's hard for me to
 tell where this problem actually comes from. Also, if anyone could advise
 me on improving my reproduction case that would be very helpful.

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