-
-
Notifications
You must be signed in to change notification settings - Fork 14k
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 on darwin when building the static library of packages that depend on packages that link with libc++ #55848
Comments
Interesting... How does haskell decide where to get c++ from? On Nix, c++ should be available as a library on every build, so it should probably just be a no-op on macOS and maybe even Linux (unless |
So the GHC panic contains the following message:
If I increase the verbosity of the build I see the following when building package
Now look what's inside
Note that the first 8 bytes of this file are
Any idea where I can find more information about this |
Of course we could also adapt GHC to support linker scripts as I mentioned in the GHC ticket... |
I don’t think linker scripts work on apple’s ld64 though. |
Building against libc++ statically involves linking in both If your linker doesn't support linker scripts you can manually link with Reverting 72e1764 will allow you to say |
This comment has been minimized.
This comment has been minimized.
@matthewbauer Yes, my point is that if you don't support linker scripts you're never going to get transparent static linking of |
Or could we perhaps modify the GHC derivation to make it use |
Hm, wait, I just noticed that GHC is already getting |
Oops sorry, just reading your replies. I do think there is some special casing clang does with stdlib: https://libcxx.llvm.org/docs/UsingLibcxx.html#getting-started But can we just say that passing just |
… is properly linked" This reverts commit 72e1764. This causes the GHC panic reported in issue NixOS#55848.
I hope to have a patch for GHC ready in the weekend. |
The patch basvandijk/ghc@b2b92dd adds limited support for linker scripts to GHC and fixes this issue. Both macos-ghc863-panic, bytestring-conversion and opencv-extra build successfully with this patch and fail to build without it. So one way forward if to revert the revert of 72e1764 and apply the patch to GHC. We could also wait and see what the GHC devs think of this patch and see if we can merge it upstream. |
Yeah it may also be possible to just make it isLinux. I'm not sure how this behaves on macOS outside of GHC. |
|
Oops yeah, alternatively |
Mm, but making the linker script's presence dependent on the stdenv used to build it doesn't seem like the way to go. What you really want is to switch it based on the linker that will be used with the library at link-time. Do we know what's responsible for passing in that |
Is there a workaround for this today? I don't fully follow what's going on here but I've recently started converting a project I have to nix and it appears to get stuck on installing
This is using nixpkgs |
@MichaelXavier that bug shouldn't appear anymore on 19.03. Could you try this with the latest |
@basvandijk indeed, updating the nixpkgs version fixed it for me. Thank you! |
Hi, I've encountered this issue again while building
|
@tscholak It looks like the channel that |
@mpickering oh, you are right, stupid me.
a little hiccup at the end, but the GHC bug is gone. cool. |
@mpickering @basvandijk @stites the renewed interest in this issue was prompted by a very similar GHC panic while building the error message is similar, but not exactly identical. have you ever seen this one:
note here the difference: the invalid magic number is not thus, while these panics look very much alike, the proposed fix in https://gitlab.haskell.org/ghc/ghc/issues/16130 and the bandaid in #56030 don't apply. PS: how would I find out which library this was caused by? |
a tiny bit of progress with the above issue:
|
Issue description
Note that by default nixpkgs builds static Haskell libraries. When you
nix-build
a Haskell package on MacOS that depends on a package that specifies to link with libc++ (i.e. has theextra-libraries: c++
cabal field) the build will fail due to a GHC panic that is triggered by aghc -staticlib ...
call.This panic doesn't happen when using other tools than Nix, like the Haskell Platform for MacOS for example.
I also reported this issue upstream at GHC ticket #16130. However, since this seems to be Nix specific, I also report it here so that we can notify the right people.
Steps to reproduce
I created a very minimal reproducible test-case with more information and observations at:
https://github.com/basvandijk/macos-ghc863-panic
The text was updated successfully, but these errors were encountered: