GHC panic when building Stack on macOS Sierra #2577
Comments
|
I was able to reproduce both locally and on Homebrew's CI. (We use GHC 8.0.1.) |
|
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. |
|
@cartazio any ideas how to fix the GHC problem with Sierra? macOS 10.12 has gone GM and Stack is dead in the water. |
|
Is it stack specific or ghc 8.0 generally? Is there a minimal repro? |
|
Since @bitemyapp's top post reports this for GHC 7.10.3, I suppose it's not specific to GHC 8.0. |
|
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 there's doubt that it's about split-sections: https://ghc.haskell.org/trac/ghc/ticket/12479#comment:4 |
|
@cartazio I think the minimal reproducer is |
|
@borsboom any idea what the problem here is? The Sierra GM has escaped into the wild! |
|
minimal code reproducer, stack is too much code |
|
@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. |
|
@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. |
|
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
changed the title
|
@bitemyapp: where did you get your GHC? Was it a sandboxed one installed by Stack? |
|
Also, from one of the GHC reports, looks like this isn't specific to Stack. yesod-auth also has a similar panic: |
I did say it was a GHC bug in the title, just trying to keep y'all apprised. |
|
If you can do a small single Haskell module repro then I and or other ghc The moment it's an issue that can be demonstrated In a self contained way, On Thursday, September 15, 2016, Emanuel Borsboom notifications@github.com
|
|
Also if the bug is in 8.0 and someone can cook up a repro I can see about On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
|
|
Looks like misty has provided some debugging data upstream to ghc. I'll On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
|
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 ... |
|
I'm pretty sure split objects is the default for the libraries. Could you On Friday, September 16, 2016, ilovezfs notifications@github.com wrote:
|
|
|
|
Could be / should be those On Friday, September 16, 2016, ilovezfs notifications@github.com wrote:
|
|
It's important to note that some builds of ghc base and boot libs may also In which case this could be a regression in linker on the OS X release. Eg Probably easy to test by unpacking the Sierra cli tools and using them on a On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
|
|
Looks like it's because they moved to llvms tool lld, and it hard coded a Me and other ghc devs are collaborating on IRC right now to confirm that On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
|
|
Ld. not dl On Friday, September 16, 2016, Carter Schonwald carter.schonwald@gmail.com
|
|
The |
|
@rwbarton: would it help to shorten the library paths within |
|
@borsboom My load commands typically look something like this: It's using 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. |
|
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. |
|
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 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. |
|
It’s still broken for me on High Sierra. I use docker container with ubuntu
and some rsync-ing to get the job done.
…On Sun, Dec 10, 2017 at 06:58 Domen Kožar ***@***.***> wrote:
@steshaw <https://github.com/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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2577 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABNscrZrcjU1uAvSLzIUBgwHMorxpRPFks5s-8dhgaJpZM4J546w>
.
|
the GHC/macOS bug appears to take effect in >=10.12 due to newly enforced limitations in linking
|
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 Stack had already done the rpath shortening trick, I think this is what remains as a more permanent fix. |
|
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 I think they need to be dependencies rather than modules? Make a Stack project that depends on |
|
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 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. |
|
@bitemyapp Nope! Didn't try that. I'll give it a shot, thanks! |
|
@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. |
|
Ah, ok that's super helpful, thanks. I added some TH and am now able to reproduce it reliably. I updated the gist. |
|
We have worked around this issue by following in the Nix folks' footsteps and using a wrapper script around The script, an example using @asivitz's repro, and more info about this issue is available here: Hope this helps! |
|
I wonder: would it be possible to modify the GHC |
|
Sure, but you have to add edit: for stack, the path for the |
|
So we could, in theory, fix this for macOS users by providing patched bindists that include the wrapper script and a modified |
|
I've changed my |
|
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨ @steshaw I'm getting I'm on stack 1.6.5. Have you seen this problem? |
|
Just ignore that warning instead of making it fail with |
|
@brandon-leapyear @gelisam I don't see that error. Perhaps it's because I updated I do get some warnings during the linking stage like this: Seems those can be safely ignored. |
and others
GHC 7.10.3
Xcode 8.0 GM, macOS Sierra
The text was updated successfully, but these errors were encountered: