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

Comments

Projects
None yet
@bitemyapp
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@zmwangx

zmwangx Sep 13, 2016

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

zmwangx commented Sep 13, 2016

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

@zmwangx

This comment has been minimized.

Show comment
Hide comment
@zmwangx

zmwangx 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.

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

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs 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.

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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio Sep 13, 2016

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

cartazio commented Sep 13, 2016

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

@zmwangx

This comment has been minimized.

Show comment
Hide comment
@zmwangx

zmwangx 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.

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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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

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

This comment has been minimized.

Show comment
Hide comment
@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

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs 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 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

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Sep 15, 2016

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

ilovezfs commented Sep 15, 2016

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

@cartazio

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio Sep 15, 2016

minimal code reproducer, stack is too much code

cartazio commented Sep 15, 2016

minimal code reproducer, stack is too much code

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 15, 2016

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@zmwangx

zmwangx 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.

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

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 15, 2016

Contributor

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).

Contributor

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 from GHC bug when upgrading to Stack master to GHC bug when upgrading to Stack master on macOS Sierra Sep 15, 2016

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 15, 2016

Contributor

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

Contributor

borsboom commented Sep 15, 2016

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

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 15, 2016

Contributor

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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Sep 15, 2016

Contributor
[ 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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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 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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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 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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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
.

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

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs 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 ...

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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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
.

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

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Sep 16, 2016

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

ilovezfs commented Sep 16, 2016

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

@zmwangx zmwangx referenced this issue Sep 16, 2016

Closed

Popular formulae with bottling trouble on 10.12 #4841

21 of 27 tasks complete
@cartazio

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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 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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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 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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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 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

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio 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
.

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 borsboom changed the title from GHC bug when upgrading to Stack master on macOS Sierra to GHC panic when building Stack on macOS Sierra Sep 16, 2016

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 16, 2016

Contributor

Is this a setting that is "baked into" the GHC binary when the bindist is built, or can it be controlled by an argument to the bindist's configure when installing the bindist (or, alternatively, by adjusting the lib/ghc-8.0.1/settings or other files after installation)?

Contributor

borsboom commented Sep 16, 2016

Is this a setting that is "baked into" the GHC binary when the bindist is built, or can it be controlled by an argument to the bindist's configure when installing the bindist (or, alternatively, by adjusting the lib/ghc-8.0.1/settings or other files after installation)?

@cartazio

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio Sep 16, 2016

The build of GHC and boot lib time thing. Default on most tier want
platforms is to enable split objects for the base and boot libs so that end
executable size is smaller

It's also a flag for userland module builds

On Sep 16, 2016 11:23 AM, "Emanuel Borsboom" notifications@github.com
wrote:

Is this a setting that is "baked into" the GHC binary when the bindist is
built, or can it be controlled by an argument to the bindist's configure
when installing the bindist (or, alternatively, by adjusting the
lib/ghc-8.0.1/settings or similar file after installation)?


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/AAAQwhj1w5pujW__B5N57yGG7ceUfbHvks5qqrSJgaJpZM4J546w
.

cartazio commented Sep 16, 2016

The build of GHC and boot lib time thing. Default on most tier want
platforms is to enable split objects for the base and boot libs so that end
executable size is smaller

It's also a flag for userland module builds

On Sep 16, 2016 11:23 AM, "Emanuel Borsboom" notifications@github.com
wrote:

Is this a setting that is "baked into" the GHC binary when the bindist is
built, or can it be controlled by an argument to the bindist's configure
when installing the bindist (or, alternatively, by adjusting the
lib/ghc-8.0.1/settings or similar file after installation)?


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/AAAQwhj1w5pujW__B5N57yGG7ceUfbHvks5qqrSJgaJpZM4J546w
.

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 16, 2016

Contributor

Ah, unfortunate. Still, we can have Stack detect that it's running on macOS >=Sierra and install GHC using alternative bindists.

Contributor

borsboom commented Sep 16, 2016

Ah, unfortunate. Still, we can have Stack detect that it's running on macOS >=Sierra and install GHC using alternative bindists.

@cartazio

This comment has been minimized.

Show comment
Hide comment
@cartazio

cartazio Sep 17, 2016

I'm not sure if that will suffice. We are still investigating

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

Ah, unfortunate. Still, we can have Stack detect that it's running on
macOS >=Sierra and install GHC using alternative bindists.


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/AAAQwrDpt8h0YR8WHS25Ej-fnCVCvsQdks5qqvGVgaJpZM4J546w
.

cartazio commented Sep 17, 2016

I'm not sure if that will suffice. We are still investigating

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

Ah, unfortunate. Still, we can have Stack detect that it's running on
macOS >=Sierra and install GHC using alternative bindists.


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/AAAQwrDpt8h0YR8WHS25Ej-fnCVCvsQdks5qqvGVgaJpZM4J546w
.

@rwbarton

This comment has been minimized.

Show comment
Hide comment
@rwbarton

rwbarton Sep 18, 2016

It's actually not a GHC bug and doesn't have to do with split objects at all. Sierra has a new limit on the "load commands size" of a shared library (that you can see mentioned in the error message) which includes the paths to its dependencies, and Stack's many dependencies and long directory paths exceed this limit.

There are possible workarounds, but I can't think of anything simple.

rwbarton commented Sep 18, 2016

It's actually not a GHC bug and doesn't have to do with split objects at all. Sierra has a new limit on the "load commands size" of a shared library (that you can see mentioned in the error message) which includes the paths to its dependencies, and Stack's many dependencies and long directory paths exceed this limit.

There are possible workarounds, but I can't think of anything simple.

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Sep 18, 2016

@rwbarton @cartazio From one of our subject matter experts:

I guess this was the hidden message behind this year's WWDC session 406 where they talked about dynamic linker internals and optimizing app startup times.

The apparent new limit of 32K enforced by 10.12 feels very conservative, but then again GHC easily blowing that limit is also a bit scary.

I think their best bet is indeed to implement the idea from the brain-storming and make sure they have only one (or very few) ⁠⁠⁠⁠LC_RPATH⁠⁠⁠⁠ load commands that cover the majority of the path prefix(es) and the remaining ⁠⁠⁠⁠LC_LOAD_DYLIB⁠⁠⁠⁠ commands build on top of that to keep things small. Having a separate ⁠⁠⁠⁠LC_RPATH⁠⁠⁠⁠ command for every single library is a bit insane (but I can totally sympathize with the simplicity of such a solution).

I know basically nothing about GHC, but if the directory layout is somewhat predictable and fixed (aside from a changing prefix), i.e. it's easy to infer where a library should be located relative to the executable/library loading it, then another solution could be to rely on ⁠⁠⁠⁠@loader_path/⁠⁠⁠⁠ and/or ⁠⁠⁠⁠@executable_path/⁠⁠⁠⁠ to avoid the lengthy and repeated prefixes.

I think they will really need to optimize the load commands they are placing in every single binary to stay below the limit. The discussed common prefix idea should be fairly simple to implement. If not directly in the compiler, then at least as a post-processing step for the binaries.

The dyld man page in its entirety, but especially the bottom was highly recommended reading.

For post-processing macho programmatically this has been suggested as a useful resource https://github.com/Homebrew/ruby-macho for various techniques.

ilovezfs commented Sep 18, 2016

@rwbarton @cartazio From one of our subject matter experts:

I guess this was the hidden message behind this year's WWDC session 406 where they talked about dynamic linker internals and optimizing app startup times.

The apparent new limit of 32K enforced by 10.12 feels very conservative, but then again GHC easily blowing that limit is also a bit scary.

I think their best bet is indeed to implement the idea from the brain-storming and make sure they have only one (or very few) ⁠⁠⁠⁠LC_RPATH⁠⁠⁠⁠ load commands that cover the majority of the path prefix(es) and the remaining ⁠⁠⁠⁠LC_LOAD_DYLIB⁠⁠⁠⁠ commands build on top of that to keep things small. Having a separate ⁠⁠⁠⁠LC_RPATH⁠⁠⁠⁠ command for every single library is a bit insane (but I can totally sympathize with the simplicity of such a solution).

I know basically nothing about GHC, but if the directory layout is somewhat predictable and fixed (aside from a changing prefix), i.e. it's easy to infer where a library should be located relative to the executable/library loading it, then another solution could be to rely on ⁠⁠⁠⁠@loader_path/⁠⁠⁠⁠ and/or ⁠⁠⁠⁠@executable_path/⁠⁠⁠⁠ to avoid the lengthy and repeated prefixes.

I think they will really need to optimize the load commands they are placing in every single binary to stay below the limit. The discussed common prefix idea should be fairly simple to implement. If not directly in the compiler, then at least as a post-processing step for the binaries.

The dyld man page in its entirety, but especially the bottom was highly recommended reading.

For post-processing macho programmatically this has been suggested as a useful resource https://github.com/Homebrew/ruby-macho for various techniques.

@UniqMartin

This comment has been minimized.

Show comment
Hide comment
@UniqMartin

UniqMartin Sep 18, 2016

Apparently I'm a “subject matter expert” and I'm the one being quoted above. I'm am contributor to the above mentioned Ruby library for dissecting and modifying Mach-O files and I'm decently knowledgeable about loaders and linkers in general and on macOS in particular.

I'm also completely clueless about GHC or Haskell in general, but if that's not a problem, I'm happy to help with some of my “wisdom”. (Disclaimer: I've also got a lot of other stuff on my plate at the moment, so I can't really promise super timely responses, but I'll try.)

UniqMartin commented Sep 18, 2016

Apparently I'm a “subject matter expert” and I'm the one being quoted above. I'm am contributor to the above mentioned Ruby library for dissecting and modifying Mach-O files and I'm decently knowledgeable about loaders and linkers in general and on macOS in particular.

I'm also completely clueless about GHC or Haskell in general, but if that's not a problem, I'm happy to help with some of my “wisdom”. (Disclaimer: I've also got a lot of other stuff on my plate at the moment, so I can't really promise super timely responses, but I'll try.)

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Sep 20, 2016

Contributor

So it sounds like this is probably something that should be fixed in properly Cabal and GHC, but may be possible to somewhat work around in Stack by shortening the paths it uses? We already do some tricks on Windows like that because of the path length limits there by putting the STACK_ROOT in C:\sr and using a hash instead of some of the longer subdirectory chains.

Contributor

borsboom commented Sep 20, 2016

So it sounds like this is probably something that should be fixed in properly Cabal and GHC, but may be possible to somewhat work around in Stack by shortening the paths it uses? We already do some tricks on Windows like that because of the path length limits there by putting the STACK_ROOT in C:\sr and using a hash instead of some of the longer subdirectory chains.

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs commented Sep 20, 2016

@borsboom definitely.

@jasonstolaruk

This comment has been minimized.

Show comment
Hide comment
@jasonstolaruk

jasonstolaruk Apr 3, 2017

@bitemyapp Yep, I was able to build just now. Looks like I'm good.

macOS Sierra 10.12.3
Stack Version 1.4.0, Git revision e714f1d (4640 commits) x86_64 hpack-0.17.0
resolver: nightly-2017-04-02

jasonstolaruk commented Apr 3, 2017

@bitemyapp Yep, I was able to build just now. Looks like I'm good.

macOS Sierra 10.12.3
Stack Version 1.4.0, Git revision e714f1d (4640 commits) x86_64 hpack-0.17.0
resolver: nightly-2017-04-02

@rwbarton

This comment has been minimized.

Show comment
Hide comment
@rwbarton

rwbarton Apr 3, 2017

This isn't and never was a GHC issue, it's a new limit added by Apple, for which a workaround was added to Cabal, which required a new feature in GHC.

If your project has enough dependencies it's possible to hit the limit again even with the workaround in place. The output of otool -l on the temporary shared object (invoke GHC with -keep-tmp-files) will clarify what is happening.

rwbarton commented Apr 3, 2017

This isn't and never was a GHC issue, it's a new limit added by Apple, for which a workaround was added to Cabal, which required a new feature in GHC.

If your project has enough dependencies it's possible to hit the limit again even with the workaround in place. The output of otool -l on the temporary shared object (invoke GHC with -keep-tmp-files) will clarify what is happening.

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Apr 3, 2017

Contributor

I don't think it's possible for Stack to do anything about this. Even if it is possible to add a workaround to Stack, it's properly fixed in Cabal and/or GHC. It's annoying when Apple does this sort of thing, but unfortunately we're stuck with it (it's not a macOS bug; they intentionally added that limit, and we will just have to adapt).

Contributor

borsboom commented Apr 3, 2017

I don't think it's possible for Stack to do anything about this. Even if it is possible to add a workaround to Stack, it's properly fixed in Cabal and/or GHC. It's annoying when Apple does this sort of thing, but unfortunately we're stuck with it (it's not a macOS bug; they intentionally added that limit, and we will just have to adapt).

@steshaw

This comment has been minimized.

Show comment
Hide comment
@steshaw

steshaw Apr 4, 2017

@chrisdone I can confirm that this still comes up for me on ghc-8.0.2 and lts-8.5 while building a yesod-based application:

    ghc: panic! (the 'impossible' happened)
      (GHC version 8.0.2 for x86_64-apple-darwin):
    	Loading temp shared object failed: dlopen(/var/folders/l2/zpkx9mks1n12dbj0cy16nfn40000gn/T/ghc34456_0/libghc_10.dylib, 5): no suitable image found.  Did find:
    	/var/folders/l2/zpkx9mks1n12dbj0cy16nfn40000gn/T/ghc34456_0/libghc_10.dylib: malformed mach-o: load commands size (33280) > 32768

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

As @rwbarton points out, you can still hit the limit even with the workaround added to Cabal.

In my case, I may be able to shorted the length of some paths because I currently soft link ~/.stack to elsewhere (in my dotfiles repo) so that it picks up my .stack/config.yaml.

I wonder if there might be any benefit in soft linking ~/.stack to say /s to shorten paths further?

steshaw commented Apr 4, 2017

@chrisdone I can confirm that this still comes up for me on ghc-8.0.2 and lts-8.5 while building a yesod-based application:

    ghc: panic! (the 'impossible' happened)
      (GHC version 8.0.2 for x86_64-apple-darwin):
    	Loading temp shared object failed: dlopen(/var/folders/l2/zpkx9mks1n12dbj0cy16nfn40000gn/T/ghc34456_0/libghc_10.dylib, 5): no suitable image found.  Did find:
    	/var/folders/l2/zpkx9mks1n12dbj0cy16nfn40000gn/T/ghc34456_0/libghc_10.dylib: malformed mach-o: load commands size (33280) > 32768

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

As @rwbarton points out, you can still hit the limit even with the workaround added to Cabal.

In my case, I may be able to shorted the length of some paths because I currently soft link ~/.stack to elsewhere (in my dotfiles repo) so that it picks up my .stack/config.yaml.

I wonder if there might be any benefit in soft linking ~/.stack to say /s to shorten paths further?

@steshaw

This comment has been minimized.

Show comment
Hide comment
@steshaw

steshaw Apr 4, 2017

A quick follow-up. For this app, I wasn't able to get it to build when I moved .stack to the usual location (ie. /Users/steshaw/.stack). However, when I soft linked /s to ~/.stack, I managed to get a successful build.

The tail end of the output from otool -l shows that the difference is made when addressing packages that come with ghc. Also, there is only a couple of hundred bytes to spare for sizeofcmds.

$ otool -l <file>.dylib | grep /s/programs
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/process-1.4.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/directory-1.3.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/filepath-1.4.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/template-haskell-2.11.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/pretty-1.1.3.3 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-boot-th-8.0.2 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/unix-2.7.2.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/time-1.6.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/transformers-0.5.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/binary-0.8.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/containers-0.5.7.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/deepseq-1.4.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/array-0.5.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/rts (offset 12)

steshaw commented Apr 4, 2017

A quick follow-up. For this app, I wasn't able to get it to build when I moved .stack to the usual location (ie. /Users/steshaw/.stack). However, when I soft linked /s to ~/.stack, I managed to get a successful build.

The tail end of the output from otool -l shows that the difference is made when addressing packages that come with ghc. Also, there is only a couple of hundred bytes to spare for sizeofcmds.

$ otool -l <file>.dylib | grep /s/programs
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/process-1.4.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/directory-1.3.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/filepath-1.4.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/template-haskell-2.11.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/pretty-1.1.3.3 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-boot-th-8.0.2 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/unix-2.7.2.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/time-1.6.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/transformers-0.5.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/binary-0.8.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/containers-0.5.7.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/deepseq-1.4.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/array-0.5.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/rts (offset 12)
@bitemyapp

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Apr 4, 2017

Contributor
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/directory-1.3.0.0 (offset 12)
Load command 125
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/filepath-1.4.1.1 (offset 12)
Load command 126
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-boot-th-8.0.2 (offset 12)
Load command 127
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 (offset 12)
Load command 128
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 (offset 12)
Load command 129
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/pretty-1.1.3.3 (offset 12)
Load command 130
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/process-1.4.3.0 (offset 12)

...

$ otool -l .stack-work/install/x86_64-osx/lts-8.4/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHSyesod-core-1.4.32-G0tj9L3iIRq7jY7gWqui14-ghc8.0.2.dylib | grep /s/programs
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/array-0.5.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/binary-0.8.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/containers-0.5.7.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/deepseq-1.4.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/directory-1.3.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/filepath-1.4.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-boot-th-8.0.2 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/pretty-1.1.3.3 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/process-1.4.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/rts (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/template-haskell-2.11.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/time-1.6.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/transformers-0.5.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/unix-2.7.2.1 (offset 12)

Thank you for sharing this tactic @steshaw, still not quite enough in my case:

(GHC version 8.0.2 for x86_64-apple-darwin):
    	Loading temp shared object failed: dlopen(/var/folders/gq/rh0h8yns2p1bb5d31mdx69b40000gn/T/ghc76548_0/libghc_33.dylib, 5): no suitable image found.  Did find:
    	/var/folders/gq/rh0h8yns2p1bb5d31mdx69b40000gn/T/ghc76548_0/libghc_33.dylib: malformed mach-o: load commands size (33288) > 32768

Other than the irritation of getting dyld to compile (you have to start vendoring the darwin userland into a build env), is there a reason people haven't made a fork that disables the byte limit? /cc @borsboom

Contributor

bitemyapp commented Apr 4, 2017

      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/directory-1.3.0.0 (offset 12)
Load command 125
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/filepath-1.4.1.1 (offset 12)
Load command 126
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-boot-th-8.0.2 (offset 12)
Load command 127
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 (offset 12)
Load command 128
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 (offset 12)
Load command 129
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/pretty-1.1.3.3 (offset 12)
Load command 130
          cmd LC_RPATH
      cmdsize 80
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/process-1.4.3.0 (offset 12)

...

$ otool -l .stack-work/install/x86_64-osx/lts-8.4/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHSyesod-core-1.4.32-G0tj9L3iIRq7jY7gWqui14-ghc8.0.2.dylib | grep /s/programs
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/array-0.5.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/binary-0.8.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/containers-0.5.7.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/deepseq-1.4.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/directory-1.3.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/filepath-1.4.1.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-boot-th-8.0.2 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/pretty-1.1.3.3 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/process-1.4.3.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/rts (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/template-haskell-2.11.1.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/time-1.6.0.1 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/transformers-0.5.2.0 (offset 12)
         path /s/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/unix-2.7.2.1 (offset 12)

Thank you for sharing this tactic @steshaw, still not quite enough in my case:

(GHC version 8.0.2 for x86_64-apple-darwin):
    	Loading temp shared object failed: dlopen(/var/folders/gq/rh0h8yns2p1bb5d31mdx69b40000gn/T/ghc76548_0/libghc_33.dylib, 5): no suitable image found.  Did find:
    	/var/folders/gq/rh0h8yns2p1bb5d31mdx69b40000gn/T/ghc76548_0/libghc_33.dylib: malformed mach-o: load commands size (33288) > 32768

Other than the irritation of getting dyld to compile (you have to start vendoring the darwin userland into a build env), is there a reason people haven't made a fork that disables the byte limit? /cc @borsboom

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Apr 4, 2017

It's the loader itself that has the limit: #2577 (comment)

ilovezfs commented Apr 4, 2017

It's the loader itself that has the limit: #2577 (comment)

@bitemyapp

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Apr 4, 2017

Contributor

@ilovezfs any idea as to why Apple did this?

Contributor

bitemyapp commented Apr 4, 2017

@ilovezfs any idea as to why Apple did this?

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Apr 4, 2017

@bitemyapp I believe it's purely an optimization measure to improve load times, but there may also be undisclosed security issues with the prior versions for all we know. (Also, no one should run into the limit in the first place when libraries are arranged as intended.)

ilovezfs commented Apr 4, 2017

@bitemyapp I believe it's purely an optimization measure to improve load times, but there may also be undisclosed security issues with the prior versions for all we know. (Also, no one should run into the limit in the first place when libraries are arranged as intended.)

@rwbarton

This comment has been minimized.

Show comment
Hide comment
@rwbarton

rwbarton Apr 4, 2017

The LC_LOAD_DYLIB load command for one library is typically 72 bytes long (depending on the library's file name length), so even with no other load commands at all (in particular, not counting any LC_RPATH entries) that puts a limit of around 500 on the number of dependencies. My understanding is that many Yesod-based projects already comfortably exceed half this number so it's a limit that does not seem very far off.

rwbarton commented Apr 4, 2017

The LC_LOAD_DYLIB load command for one library is typically 72 bytes long (depending on the library's file name length), so even with no other load commands at all (in particular, not counting any LC_RPATH entries) that puts a limit of around 500 on the number of dependencies. My understanding is that many Yesod-based projects already comfortably exceed half this number so it's a limit that does not seem very far off.

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Apr 5, 2017

Contributor

@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).

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Apr 5, 2017

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Jul 20, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@steshaw

steshaw 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?

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

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Dec 10, 2017

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@EugeneN

EugeneN Dec 10, 2017

EugeneN commented Dec 10, 2017

agentm added a commit to agentm/project-m36 that referenced this issue Jan 7, 2018

use oldest possible macOS to avoid commercialhaskell/stack#2577
the GHC/macOS bug appears to take effect in >=10.12 due to newly enforced limitations in linking
@asivitz

This comment has been minimized.

Show comment
Hide comment
@asivitz

asivitz 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?

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Feb 27, 2018

Contributor

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

NixOS/nixpkgs#27536

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@asivitz

asivitz 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

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Feb 27, 2018

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@asivitz

asivitz 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.

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Feb 27, 2018

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@asivitz

asivitz Feb 28, 2018

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

asivitz commented Feb 28, 2018

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

@bitemyapp

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Feb 28, 2018

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@asivitz

asivitz 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.

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

This comment has been minimized.

Show comment
Hide comment
@jship

jship 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!

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

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Apr 18, 2018

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@gelisam

gelisam 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

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

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Apr 19, 2018

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@steshaw

steshaw 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")

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

This comment has been minimized.

Show comment
Hide comment
@brandon-leapyear

brandon-leapyear 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?

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

This comment has been minimized.

Show comment
Hide comment
@gelisam

gelisam 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.

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

This comment has been minimized.

Show comment
Hide comment
@steshaw

steshaw 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.

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