Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GHC panic when building Stack on macOS Sierra #2577

Closed
bitemyapp opened this issue Sep 11, 2016 · 140 comments
Closed

GHC panic when building Stack on macOS Sierra #2577

bitemyapp opened this issue Sep 11, 2016 · 140 comments

Comments

@bitemyapp
Copy link
Contributor

@bitemyapp bitemyapp commented Sep 11, 2016

GHC 7.10.3

stack upgrade --git
$ uname -a
Darwin cumae.local 16.0.0 Darwin Kernel Version 16.0.0: Tue Aug 23 17:02:44 PDT 2016; root:xnu-3789.1.31~2/RELEASE_X86_64 x86_64

Xcode 8.0 GM, macOS Sierra

Preprocessing library stack-1.2.1...
[ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )
[ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )
[ 3 of 96] Compiling Stack.FileWatch  ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )
[ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )
[ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )
[ 6 of 96] Compiling Paths_stack      ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )
[ 7 of 96] Compiling Path.Find        ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )
[ 8 of 96] Compiling Path.Extra       ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )
[ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-apple-darwin):
        Loading temp shared object failed: dlopen(/var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/ghc29687_0/libghc_55.dylib, 5): no suitable image found.  Did find:
        /var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/ghc29687_0/libghc_55.dylib: malformed mach-o: load commands size (46680) > 32768

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Completed 178 action(s).

--  While building package stack-1.2.1 using:
      /private/var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/stack-upgrade18342/stack/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
@zmwangx
Copy link

@zmwangx zmwangx commented Sep 13, 2016

I was able to reproduce both locally and on Homebrew's CI. (We use GHC 8.0.1.)

@zmwangx
Copy link

@zmwangx zmwangx commented Sep 13, 2016

Maybe the title could be a little bit more informative. This is only a problem on macOS 10.12 Sierra as far as I can tell.

@ilovezfs
Copy link

@ilovezfs ilovezfs commented Sep 13, 2016

@cartazio any ideas how to fix the GHC problem with Sierra? macOS 10.12 has gone GM and Stack is dead in the water.

@cartazio
Copy link

@cartazio cartazio commented Sep 13, 2016

Is it stack specific or ghc 8.0 generally? Is there a minimal repro?

@zmwangx
Copy link

@zmwangx zmwangx commented Sep 13, 2016

Since @bitemyapp's top post reports this for GHC 7.10.3, I suppose it's not specific to GHC 8.0.

@cartazio
Copy link

@cartazio cartazio commented Sep 13, 2016

It looks like it's related to split objects or sections?

It would help if there was a simpler application that reported this issue

@ilovezfs
Copy link

@ilovezfs ilovezfs commented Sep 13, 2016

@cartazio there's doubt that it's about split-sections: https://ghc.haskell.org/trac/ghc/ticket/12479#comment:4

@ilovezfs
Copy link

@ilovezfs ilovezfs commented Sep 13, 2016

@cartazio I think the minimal reproducer is brew instal -s stack at this point, but it looks like it really doesn't get very far

Building stack-1.1.2...
Preprocessing library stack-1.1.2...
[ 1 of 87] Compiling Stack.FileWatch  ( src/Stack/FileWatch.hs, dist/dist-sandbox-68bf8d9c/build/Stack/FileWatch.o )
[ 2 of 87] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/dist-sandbox-68bf8d9c/build/System/Process/PagerEditor.o )
[ 3 of 87] Compiling System.Process.Log ( src/System/Process/Log.hs, dist/dist-sandbox-68bf8d9c/build/System/Process/Log.o )
[ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-68bf8d9c/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-apple-darwin):
    Loading temp shared object failed: dlopen(/var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc94633_0/libghc_44.dylib, 5): no suitable image found.  Did find:
    /var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc94633_0/libghc_44.dylib: malformed mach-o: load commands size (40192) > 32768
@ilovezfs
Copy link

@ilovezfs ilovezfs commented Sep 15, 2016

@borsboom any idea what the problem here is? The Sierra GM has escaped into the wild!

@cartazio
Copy link

@cartazio cartazio commented Sep 15, 2016

minimal code reproducer, stack is too much code

@borsboom
Copy link
Contributor

@borsboom borsboom commented Sep 15, 2016

@ilovezfs No idea. It has to be a GHC bug (panics always are) but would be nice to find a workaround. I don't have an Apple developer account, so I don't have any access to Sierra betas. Once it's released I can upgrade my spare mac Mini and try to reproduce.

@zmwangx
Copy link

@zmwangx zmwangx commented Sep 15, 2016

@borsboom The public beta is already on GM so you don't need to have a developer subscription to have access to pretty much the final version of 10.12.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Sep 15, 2016

If anyone else has some time, I'd probably start trying to make a smaller reproduction by extracting the failing System.Process.Read module to a separate project and minimizing the dependencies. It's an isolated module so that should be pretty easy. If it still fails, just start taking out pieces of code until you find what triggers the panic (if it doesn't fail... well then it's more complicated I guess).

@borsboom borsboom changed the title GHC bug when upgrading to Stack master GHC bug when upgrading to Stack master on macOS Sierra Sep 15, 2016
@borsboom
Copy link
Contributor

@borsboom borsboom commented Sep 15, 2016

@bitemyapp: where did you get your GHC? Was it a sandboxed one installed by Stack?

@borsboom
Copy link
Contributor

@borsboom borsboom commented Sep 15, 2016

Also, from one of the GHC reports, looks like this isn't specific to Stack. yesod-auth also has a similar panic:

   [ 4 of 11] Compiling Yesod.Auth       ( Yesod/Auth.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth.o )
    ghc: panic! (the 'impossible' happened)
      (GHC version 7.10.2 for x86_64-apple-darwin):
        Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib, 5): no suitable image found.  Did find:
        /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib: malformed mach-o: load commands size (34176) > 32768
@bitemyapp
Copy link
Contributor Author

@bitemyapp bitemyapp commented Sep 15, 2016

[ callen@cumae ~/work/codex travisci-build-matrix-stack ✔ ]
$ stack exec -- ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
[ callen@cumae ~/work/codex travisci-build-matrix-stack ✔ ]
$ stack exec -- which ghc
/Users/callen/.stack/programs/x86_64-osx/ghc-7.10.3/bin/ghc

I did say it was a GHC bug in the title, just trying to keep y'all apprised.

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

If you can do a small single Haskell module repro then I and or other ghc
dev team folk can dig into resolving it. But without a clear minimal repro
that 8.0 can trigger with a small module and clear deps, hard to do.

The moment it's an issue that can be demonstrated In a self contained way,
it'll be a ghc bug that gets full focus by applicable volunteers. Ghc
contributors don't have the bandwidth to boil down a repro from a really
large application

On Thursday, September 15, 2016, Emanuel Borsboom notifications@github.com
wrote:

If anyone else has some time, I'd probably start trying to make a smaller
reproduction by extracting the failing System.Process.Read module to a
separate project and minimizing the dependencies. It's an isolated module
so that should be pretty easy. If it still fails, just start taking out
pieces of code until you find what triggers the panic (if it doesn't
fail... well then it's more complicated I guess).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwlfNd2gRtHcsG-i2fqj47rYNnKgVks5qqaTKgaJpZM4J546w
.

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

Also if the bug is in 8.0 and someone can cook up a repro I can see about
sorting out a fix and making sure it's in an 8.0 bug fix. But I can't do
that until there's a small self contained small code base that has the
problem

On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
wrote:

If you can do a small single Haskell module repro then I and or other ghc
dev team folk can dig into resolving it. But without a clear minimal repro
that 8.0 can trigger with a small module and clear deps, hard to do.

The moment it's an issue that can be demonstrated In a self contained way,
it'll be a ghc bug that gets full focus by applicable volunteers. Ghc
contributors don't have the bandwidth to boil down a repro from a really
large application

On Thursday, September 15, 2016, Emanuel Borsboom <
notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

If anyone else has some time, I'd probably start trying to make a smaller
reproduction by extracting the failing System.Process.Read module to a
separate project and minimizing the dependencies. It's an isolated module
so that should be pretty easy. If it still fails, just start taking out
pieces of code until you find what triggers the panic (if it doesn't
fail... well then it's more complicated I guess).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwlfNd2gRtHcsG-i2fqj47rYNnKgVks5qqaTKgaJpZM4J546w
.

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

Looks like misty has provided some debugging data upstream to ghc. I'll
talk with bengamari. His current theory is that somehow the offending
builds have split sections enabled. And thus are drowning the linker

On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
wrote:

Also if the bug is in 8.0 and someone can cook up a repro I can see about
sorting out a fix and making sure it's in an 8.0 bug fix. But I can't do
that until there's a small self contained small code base that has the
problem

On Friday, September 16, 2016, Carter Schonwald <
carter.schonwald@gmail.com
javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');> wrote:

If you can do a small single Haskell module repro then I and or
other ghc dev team folk can dig into resolving it. But without a clear
minimal repro that 8.0 can trigger with a small module and clear deps, hard
to do.

The moment it's an issue that can be demonstrated In a self contained
way, it'll be a ghc bug that gets full focus by applicable volunteers. Ghc
contributors don't have the bandwidth to boil down a repro from a really
large application

On Thursday, September 15, 2016, Emanuel Borsboom <
notifications@github.com> wrote:

If anyone else has some time, I'd probably start trying to make a
smaller reproduction by extracting the failing System.Process.Read module
to a separate project and minimizing the dependencies. It's an isolated
module so that should be pretty easy. If it still fails, just start taking
out pieces of code until you find what triggers the panic (if it doesn't
fail... well then it's more complicated I guess).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwlfNd2gRtHcsG-i2fqj47rYNnKgVks5qqaTKgaJpZM4J546w
.

@ilovezfs
Copy link

@ilovezfs ilovezfs commented Sep 16, 2016

His current theory is that somehow the offending builds have split sections enabled.

which would be quite weird since as misty also pointed out it seems to be a non-default option that we didn't pass in, but that doesn't mean it's impossible it built that way anyway for some reason ...

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

I'm pretty sure split objects is the default for the libraries. Could you
try disabling that? I could be misremembering. Also I'm totally weak at
linker stuff

On Friday, September 16, 2016, ilovezfs notifications@github.com wrote:

His current theory is that somehow the offending builds have split
sections enabled.

which would be quite weird since as misty also pointed out it seems to be
a non-default option that we didn't pass in, but that doesn't mean it's
impossible it built that way anyway for some reason ...


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwhcph23yUUDuzVrrMcW5uam3W4M0ks5qqhzmgaJpZM4J546w
.

@ilovezfs
Copy link

@ilovezfs ilovezfs commented Sep 16, 2016

--disable-split-objs and --disable-split-sections?

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

Could be / should be those

On Friday, September 16, 2016, ilovezfs notifications@github.com wrote:

--disable-split-objs and --disable-split-sections?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwjyBGkFtBJ8zvJI5KsIsa7GtGthcks5qqia7gaJpZM4J546w
.

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

It's important to note that some builds of ghc base and boot libs may also
have those flags enabled.

In which case this could be a regression in linker on the OS X release. Eg
is it a format limit or a hard coded "safety limit" in the Sierra linker?
Are they still using gnu linker or move to llvm? In latter case is there
some hard coded sanity limits?

Probably easy to test by unpacking the Sierra cli tools and using them on a
previous os release.

On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
wrote:

Could be / should be those

On Friday, September 16, 2016, ilovezfs <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

--disable-split-objs and --disable-split-sections?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwjyBGkFtBJ8zvJI5KsIsa7GtGthcks5qqia7gaJpZM4J546w
.

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

Looks like it's because they moved to llvms tool lld, and it hard coded a
limit on number of sections it'll accept. So the near term mitigation
would be to disable split objects on a ghc Mac build , but the Better
medium / long term is
A) we all fire radars on this
B) we make sure that upstream lld is fixed.

Me and other ghc devs are collaborating on IRC right now to confirm that
we've isolated the problem. Affected users could also unpack a pre Sierra
cli tools and put dl in their path as an alternative mitigation (this is me
speculating on an approach I have not tested but would probably work fine )

On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
wrote:

Looks like misty has provided some debugging data upstream to ghc. I'll
talk with bengamari. His current theory is that somehow the offending
builds have split sections enabled. And thus are drowning the linker

On Friday, September 16, 2016, Carter Schonwald <
carter.schonwald@gmail.com
javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');> wrote:

Also if the bug is in 8.0 and someone can cook up a repro I can see about
sorting out a fix and making sure it's in an 8.0 bug fix. But I can't do
that until there's a small self contained small code base that has the
problem

On Friday, September 16, 2016, Carter Schonwald <
carter.schonwald@gmail.com> wrote:

If you can do a small single Haskell module repro then I and or
other ghc dev team folk can dig into resolving it. But without a clear
minimal repro that 8.0 can trigger with a small module and clear deps, hard
to do.

The moment it's an issue that can be demonstrated In a self contained
way, it'll be a ghc bug that gets full focus by applicable volunteers. Ghc
contributors don't have the bandwidth to boil down a repro from a really
large application

On Thursday, September 15, 2016, Emanuel Borsboom <
notifications@github.com> wrote:

If anyone else has some time, I'd probably start trying to make a
smaller reproduction by extracting the failing System.Process.Read module
to a separate project and minimizing the dependencies. It's an isolated
module so that should be pretty easy. If it still fails, just start taking
out pieces of code until you find what triggers the panic (if it doesn't
fail... well then it's more complicated I guess).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwlfNd2gRtHcsG-i2fqj47rYNnKgVks5qqaTKgaJpZM4J546w
.

@cartazio
Copy link

@cartazio cartazio commented Sep 16, 2016

Ld. not dl

On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
wrote:

Looks like it's because they moved to llvms tool lld, and it hard coded a
limit on number of sections it'll accept. So the near term mitigation
would be to disable split objects on a ghc Mac build , but the Better
medium / long term is
A) we all fire radars on this
B) we make sure that upstream lld is fixed.

Me and other ghc devs are collaborating on IRC right now to confirm that
we've isolated the problem. Affected users could also unpack a pre Sierra
cli tools and put dl in their path as an alternative mitigation (this is me
speculating on an approach I have not tested but would probably work fine
)

On Friday, September 16, 2016, Carter Schonwald <
carter.schonwald@gmail.com
javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');> wrote:

Looks like misty has provided some debugging data upstream to ghc. I'll
talk with bengamari. His current theory is that somehow the offending
builds have split sections enabled. And thus are drowning the linker

On Friday, September 16, 2016, Carter Schonwald <
carter.schonwald@gmail.com> wrote:

Also if the bug is in 8.0 and someone can cook up a repro I can see
about sorting out a fix and making sure it's in an 8.0 bug fix. But I can't
do that until there's a small self contained small code base that has the
problem

On Friday, September 16, 2016, Carter Schonwald <
carter.schonwald@gmail.com> wrote:

If you can do a small single Haskell module repro then I and or
other ghc dev team folk can dig into resolving it. But without a clear
minimal repro that 8.0 can trigger with a small module and clear deps, hard
to do.

The moment it's an issue that can be demonstrated In a self contained
way, it'll be a ghc bug that gets full focus by applicable volunteers. Ghc
contributors don't have the bandwidth to boil down a repro from a really
large application

On Thursday, September 15, 2016, Emanuel Borsboom <
notifications@github.com> wrote:

If anyone else has some time, I'd probably start trying to make a
smaller reproduction by extracting the failing System.Process.Read module
to a separate project and minimizing the dependencies. It's an isolated
module so that should be pretty easy. If it still fails, just start taking
out pieces of code until you find what triggers the panic (if it doesn't
fail... well then it's more complicated I guess).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2577 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwlfNd2gRtHcsG-i2fqj47rYNnKgVks5qqaTKgaJpZM4J546w
.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Apr 5, 2017

@rwbarton: would it help to shorten the library paths within ~/.stack? On Windows replace some of the deeper paths with a short hash to work around path length limits, and we could do something like that on macOS too (although I'd much rather not, since it makes it harder for a human to navigate ~/.stack).

@bitemyapp
Copy link
Contributor Author

@bitemyapp bitemyapp commented Apr 5, 2017

@borsboom My load commands typically look something like this:

          cmd LC_LOAD_DYLIB
      cmdsize 72
         name @rpath/libHSghc-boot-th-8.0.2-ghc8.0.2.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969

It's using @rpath to handle the path prefix. I don't know how the bytes are calculated by the runtime loader, but I'm not sure what more you can do.

This is a touch frustrating as the project that won't build is a pretty young Yesod project with not many extra dependencies beyond Yesod + lens.

@domenkozar
Copy link
Contributor

@domenkozar domenkozar commented Jul 20, 2017

Stack could create a library in intermediate steps, while the tree of dynamic libraries would be bigger, the limit could be mitigated.

I'm looking into possible solutions, for Nix one would be just to patch Apple source.

@steshaw
Copy link

@steshaw steshaw commented Dec 10, 2017

Can anyone confirm that this is fixed in macOS High Sierra? I was previously on Sierra but had to wipe my machine and downgrade to El Capitan to get work done. I'm wondering if it's safe to upgrade to High Sierra for a yesod project with lots of dependencies (342 ?!?).

As far as I can tell, the GHC bug is fixed ... but it does look like someone had a similar problem on Sierra with it 7 weeks ago. Probably not fixed?

@domenkozar
Copy link
Contributor

@domenkozar domenkozar commented Dec 10, 2017

@steshaw it's not fixed, as the GHC fix only makes it harder to hit the limit in linker.

In Nix, we have a hack to reexport symbols to never reach the limit in one executable, so that should work with Stack.

I suggest you try out your project on Sierra (High Sierra doesn't change anything) and try to use Nix to provide the linker hack.

Long term solution is for haskell libraries not to use such long paths, now that stack/nix use separate folders and naming doesn't have to account for namespacing.

@EugeneN
Copy link

@EugeneN EugeneN commented Dec 10, 2017

agentm added a commit to agentm/project-m36 that referenced this issue Jan 7, 2018
the GHC/macOS bug appears to take effect in >=10.12 due to newly enforced limitations in linking
@asivitz
Copy link

@asivitz asivitz commented Feb 27, 2018

I am running into this as well. Would it be reasonable to use Nix's workaround inside Stack? I am not familiar with Stack's internals, but if anyone thinks that would be a good approach I can investigate it.

Also, perhaps this issue should be reopened?

@bitemyapp
Copy link
Contributor Author

@bitemyapp bitemyapp commented Feb 27, 2018

@asivitz Stack had already done the rpath shortening trick, I think this is what remains as a more permanent fix.

NixOS/nixpkgs#27536

@asivitz
Copy link

@asivitz asivitz commented Feb 27, 2018

Yikes, I think that's a little more involved than I hoped.

Btw, I tried to make a controlled reproduction case by generating a giant stack project with a bunch of sub-packages, but I couldn't cause the panic. I wonder what I'm missing? https://gist.github.com/asivitz/f4b983b2374a6155ac4faaf9b61aca59

@bitemyapp
Copy link
Contributor Author

@bitemyapp bitemyapp commented Feb 27, 2018

@asivitz I think they need to be dependencies rather than modules? Make a Stack project that depends on acme-everything and see if that trips it.

@asivitz
Copy link

@asivitz asivitz commented Feb 27, 2018

They are dependencies actually. It's a top-level library that depends on 400 sub-packages. It's pretty weird because when I looked at the output for my failure it was around 300 deps, and this one has 400 (and longer filenames also) and it doesn't trip it.

@bitemyapp
Copy link
Contributor Author

@bitemyapp bitemyapp commented Feb 27, 2018

@asivitz Oh my bad, I only glanced at the script. I've found reproducing the failure with Stack to be inconsistent in this way too, FWIW.

Did you try executing it or using some Template Haskell in it? I think you can force a linker failure during compile-time if you use TH.

@asivitz
Copy link

@asivitz asivitz commented Feb 28, 2018

@bitemyapp Nope! Didn't try that. I'll give it a shot, thanks!

@bitemyapp
Copy link
Contributor Author

@bitemyapp bitemyapp commented Feb 28, 2018

@asivitz AIUI this is the runtime linker in the Darwin kernel that is imposing the kilobyte limit on the paths. macOS doesn't actually permit static linking at all. Given that, the only way to trip it that I'm aware of is for TH to force runtime linking at compile time or to run the program.

@asivitz
Copy link

@asivitz asivitz commented Feb 28, 2018

Ah, ok that's super helpful, thanks. I added some TH and am now able to reproduce it reliably. I updated the gist.

@jship
Copy link

@jship jship commented Apr 18, 2018

We have worked around this issue by following in the Nix folks' footsteps and using a wrapper script around ld to recursively subdivide the dependencies into a tree of re-exporting delegate libraries.

The script, an example using @asivitz's repro, and more info about this issue is available here:
https://github.com/Simspace/ld-wrapper-macos

Hope this helps!

@borsboom
Copy link
Contributor

@borsboom borsboom commented Apr 18, 2018

I wonder: would it be possible to modify the GHC settings file to use this wrapper for all builds (rather than having to add the flag to every project)? If so, it would be possible to have Stack use patched GHC bindists on macOS that includes this fix.

@gelisam
Copy link

@gelisam gelisam commented Apr 19, 2018

Sure, but you have to add -fuse-ld=ld-wrapper-macos.sh to the C compiler flags section of the settings file, you can't simply set the ld command option.

edit: for stack, the path for the settings file looks like ~/.stack/programs/x86_64-osx/ghc-8.2.2/lib/ghc-8.2.2/settings

@borsboom
Copy link
Contributor

@borsboom borsboom commented Apr 19, 2018

So we could, in theory, fix this for macOS users by providing patched bindists that include the wrapper script and a modified configure to update settings to use it on macOS >= 10.12. I'm always hesitant about this sort of thing, because it's one more thing we have to support going forward and would be best fixed by the GHC team themselves, but in this case there are enough macOS users and this causes enough pain that it might be worth doing.

@steshaw
Copy link

@steshaw steshaw commented Apr 20, 2018

I've changed my settings to have the following flags and it built my project on High Sierra. Thank you!

("C compiler link flags", " -m64 -fuse-ld=ld-wrapper-macos.sh")
@brandon-leapyear
Copy link
Contributor

@brandon-leapyear brandon-leapyear commented May 10, 2018

@steshaw I'm getting

clang: error: argument unused during compilation: '-fuse-ld=ld-wrapper-macos.sh' [-Werror,-Wunused-command-line-argument]

I'm on stack 1.6.5. Have you seen this problem?

@gelisam
Copy link

@gelisam gelisam commented May 10, 2018

Just ignore that warning instead of making it fail with -Werror; the warning comes from clang, who noticed that you gave it linking flags in a clang invocation which doesn't perform any linking. This in turn occurs because adding -fuse-ld=ld-wrapper-macos.sh to C compiler link flags causes ghc to add this flag to all of its invocations of clang, both those which perform linking and those which don't.

@steshaw
Copy link

@steshaw steshaw commented May 10, 2018

@brandon-leapyear @gelisam I don't see that error. Perhaps it's because I updated C compiler link flags rather than C compiler flags in ~/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/settings.

I do get some warnings during the linking stage like this:

/Users/steshaw/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/include/rts/storage/ClosureMacros.h:552:32: error:
     warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
#if ZERO_SLOP_FOR_LDV_PROF && !ZERO_SLOP_FOR_SANITY_CHECK
                               ^
...
9 warnings generated.

Seems those can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.