GHC panic on darwin when building the static library of packages that depend on packages that link with libc++ #55848

basvandijk · 2019-02-15T19:31:58Z

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 a ghc -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:

matthewbauer · 2019-02-15T20:19:03Z

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 extra-libraries: c++ is saying to use LLVM's libcxx and not GCC's libstdcxx).

basvandijk · 2019-02-15T21:44:22Z

So the GHC panic contains the following message:

Data.Binary.Get.runGet at position 8: Invalid magic number "INPUT(-l"

If I increase the verbosity of the build I see the following when building package a (from my test-case):

> nix-build -A haskellPackages.a
...
/nix/store/r348h4r4nsmc534239cgq7m51kyyzzrl-ghc-8.6.3/bin/ghc
  -staticlib
  '-lc++'
  '-L/nix/store/jv40yw2ny28nnpbf860aaqq1dhga0f0r-libc++-5.0.2/lib'
  '-L/nix/store/hgqs9r48niq50xzvgnz7prbykizpy4mk-libc++abi-5.0.2/lib'
  -L/nix/store/r6aijfn3pi3k11rddrw9531pwglhrblr-compiler-rt-5.0.2/lib
  -L/nix/store/0lqb3vjib31xyr8iadc8rib9bpl8mf5m-ncurses-6.1-20181027/lib
  -L/nix/store/0jn6j8ya9zffqd427rjhalhrfqcldalf-gmp-6.1.2/lib
  -L/nix/store/r0wvw1pk9sdylb308zn4hp5j0r6v6ak6-libiconv-osx-10.11.6/lib
  -this-unit-id a-0.1.0.0-CQnIe1qPUVV66BMgXSBVV1
  -hide-all-packages
  -no-auto-link-packages
  -no-user-package-db
  -package-db /private/tmp/nix-build-a-0.1.0.0.drv-0/package.conf.d
  -package-db dist/package.conf.inplace
  -package-id base-4.12.0.0
  dist/build/A.o
  -o dist/build/libHSa-0.1.0.0-CQnIe1qPUVV66BMgXSBVV1-ghc8.6.3.a
  -j1

Now look what's inside libc++.a:

> cat /nix/store/jv40yw2ny28nnpbf860aaqq1dhga0f0r-libc++-5.0.2/lib/libc++.a
INPUT(-lc++_static -lc++abi)

Note that the first 8 bytes of this file are INPUT(- which is exactly what GHC is panicking about. It seems that GHC is expecting libc++.a to be a binary archive while in fact it's some kind of textual reference to the real archive libc++_static.a which can be found in the same directory..

> ls -la /nix/store/jv40yw2ny28nnpbf860aaqq1dhga0f0r-libc++-5.0.2/lib
total 4896
dr-xr-xr-x  8 root  wheel      256 Dec 31  1969 .
dr-xr-xr-x  5 root  wheel      160 Dec 31  1969 ..
-r-xr-xr-x  1 root  wheel   886132 Dec 31  1969 libc++.1.0.dylib
lrwxr-xr-x  1 root  wheel       16 Dec 31  1969 libc++.1.dylib -> libc++.1.0.dylib
-r--r--r--  1 root  wheel       29 Dec 31  1969 libc++.a
lrwxr-xr-x  1 root  wheel       14 Dec 31  1969 libc++.dylib -> libc++.1.dylib
-r--r--r--  1 root  wheel  1472712 Dec 31  1969 libc++_static.a
-r--r--r--  1 root  wheel   139216 Dec 31  1969 libc++experimental.a

Any idea where I can find more information about this INPUT(-lc++_static -lc++abi) mechanism?

matthewbauer · 2019-02-15T21:59:46Z

Yeah this looks wrong:

72e1764

We should be building these starically.

/cc @Twey

Why is this being done? We should see if reverting fixes this.

basvandijk · 2019-02-15T22:02:01Z

@Twey why do we need 72e1764? GHC is tripping over it.

basvandijk · 2019-02-15T22:50:46Z

Of course we could also adapt GHC to support linker scripts as I mentioned in the GHC ticket...

matthewbauer · 2019-02-15T23:13:31Z

I don’t think linker scripts work on apple’s ld64 though.

Twey · 2019-02-16T00:01:45Z

Building against libc++ statically involves linking in both libc++_static and libc++abi (a dependency of libc++). The standard way to do this seems to be with a linker script like this one that tells the linker that whenever it wants to link in libc++ statically it should link in those two instead.

If your linker doesn't support linker scripts you can manually link with libc++_static and libc++abi, but you're never going to be able to just say -lc++.

Reverting 72e1764 will allow you to say -lc++ instead of -lc++_static, but you're still going to have to link in libc++abi manually when you link statically (and anyone who just tries to link statically against libc++ will break). A better workaround for a lack of linker script support might be to provide pkgconfig for libc++: pkg-config --static --libs libc++ could return -lc++_static -lc++abi.

Twey · 2019-02-16T14:34:02Z

@matthewbauer Yes, my point is that if you don't support linker scripts you're never going to get transparent static linking of libc++ anyway, because it has a private dependency. So you might as well just not use the linker script and manually make extra-libraries: c++_static, c++abi… or use an external tool like pkg-config to abstract over it for you. I don't know how people normally statically link libc++ on Darwin; perhaps there's some ld64 equivalent of linker scripts or some other standard external tool? It might also just be that Clang special-cases it, in which case GHC is on its own.

Twey · 2019-02-16T14:35:24Z

Or could we perhaps modify the GHC derivation to make it use ld instead?

Twey · 2019-02-16T14:38:37Z

Hm, wait, I just noticed that GHC is already getting libc++abifrom somewhere. Perhaps we should remove the linker script and add a special case to libcxxStdenv for static linking instead?

matthewbauer · 2019-02-17T04:43:38Z

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 -lc++ is okay to be broken? I assume it had been broken before that commit? It looks like that’s what LLVM assumes and in general it’s easiest to just defer to upstream on these kind of things. Dealing with hacks, special casing, and custom library names doesn’t seem worth it to me.

… is properly linked" This reverts commit 72e1764. This causes the GHC panic reported in issue NixOS#55848.

matthewbauer · 2019-02-19T16:47:12Z

I reverted this today so that this wouldn't be broken in 19.03 (#56030). I definitely want to get static libc++ working as was intended in #51960, though. We may just need to patch ghc844 to handle this.

basvandijk · 2019-02-19T22:33:09Z

I hope to have a patch for GHC ready in the weekend.

basvandijk · 2019-02-25T00:25:53Z

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.

matthewbauer · 2019-02-25T00:45:31Z

Yeah it may also be possible to just make it isLinux. I'm not sure how this behaves on macOS outside of GHC.

Twey · 2019-02-25T14:39:09Z

isLinux doesn't seem broad enough in scope — unless you're using ld64 I imagine you always need to have the linker script for static -lc++ to work. Maybe not isDarwin? But even so I imagine you could have linkers on Darwin that don't have the libc++ special-casing.

matthewbauer · 2019-02-25T15:06:42Z

Oops yeah, alternatively !stdenv.cc.isClang but we will need to test how Clang handles this. I think clang++ just adds it for you.

Twey · 2019-02-26T00:45:14Z

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 -L/nix/store/hgqs9r48niq50xzvgnz7prbykizpy4mk-libc++abi-5.0.2/lib to GHC?

MichaelXavier · 2019-04-10T15:50:16Z

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 formattable-0.1.1

Preprocessing library for formattable-0.1.1..
Building library for formattable-0.1.1..
[1 of 3] Compiling Formattable.NumFormat ( src/Formattable/NumFormat.hs, dist/build/Formattable/NumFormat.o )

src/Formattable/NumFormat.hs:55:1: warning: [-Wunused-imports]
    The import of ‘Control.Applicative’ is redundant
      except perhaps to import instances from ‘Control.Applicative’
    To import instances alone, use: import Control.Applicative()
   |
55 | import           Control.Applicative
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Formattable/NumFormat.hs:59:1: warning: [-Wunused-imports]
    The import of ‘Data.Monoid’ is redundant
      except perhaps to import instances from ‘Data.Monoid’
    To import instances alone, use: import Data.Monoid()
   |
59 | import           Data.Monoid
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[2 of 3] Compiling Formattable      ( src/Formattable.hs, dist/build/Formattable.o )

src/Formattable.hs:32:1: warning: [-Wunused-imports]
    The import of ‘Data.Time’ is redundant
      except perhaps to import instances from ‘Data.Time’
    To import instances alone, use: import Data.Time()
   |
32 | import           Data.Time
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^
[3 of 3] Compiling Formattable.TimeDiff ( src/Formattable/TimeDiff.hs, dist/build/Formattable/TimeDiff.o )

src/Formattable/TimeDiff.hs:19:1: warning: [-Wunused-imports]
    The import of ‘Data.Monoid’ is redundant
      except perhaps to import instances from ‘Data.Monoid’
    To import instances alone, use: import Data.Monoid()
   |
19 | import           Data.Monoid
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ld: warning: /nix/store/spx9xz1jv3yhmqw8y3agki1fvdr2x2fv-libiconv-osx-10.11.6/lib/libiconv.dylib, ignoring unexpected dylib file
ghc: panic! (the 'impossible' happened)
  (GHC version 8.6.3 for x86_64-apple-darwin):
        Data.Binary.Get.runGet at position 8: Invalid magic number "INPUT(-l"
CallStack (from HasCallStack):
  error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.6.0:Data.Binary.Get

This is using nixpkgs 19.03-beta

basvandijk · 2019-04-15T10:56:38Z

@MichaelXavier that bug shouldn't appear anymore on 19.03. Could you try this with the latest release-19.03 because I see the fix 8cb7ea7 was merged into that branch on Feb 19.

MichaelXavier · 2019-04-15T18:46:10Z

@basvandijk indeed, updating the nixpkgs version fixed it for me. Thank you!

tscholak · 2019-09-05T17:48:55Z

Hi, I've encountered this issue again while building haskellPackages.text-format (and others that depend on packages built with extra-libraries: c++ like double-conversion, see http://hackage.haskell.org/package/double-conversion-2.0.2.0/src/double-conversion.cabal):

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 18.6.0, macOS 10.14.5`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.2.1`
 - channels(tscholak): `"nixpkgs-19.09pre190327.54f385241e6"`
 - channels(root): `"nixpkgs-19.03pre166740.422b6bd489a"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

$ nix-build '<nixpkgs>' -A haskellPackages.text-format
these derivations will be built:
  /nix/store/jwy4qln0p2dx30vbky014dp63kj5cqpv-text-format-0.3.2.drv
building '/nix/store/jwy4qln0p2dx30vbky014dp63kj5cqpv-text-format-0.3.2.drv'...
...
ghc: panic! (the 'impossible' happened)
  (GHC version 8.6.3 for x86_64-apple-darwin):
        Data.Binary.Get.runGet at position 8: Invalid magic number "INPUT(-l"
CallStack (from HasCallStack):
  error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.6.0:Data.Binary.Get

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

builder for '/nix/store/jwy4qln0p2dx30vbky014dp63kj5cqpv-text-format-0.3.2.drv' failed with exit code 1
error: build of '/nix/store/jwy4qln0p2dx30vbky014dp63kj5cqpv-text-format-0.3.2.drv' failed

idontgetoutmuch · 2019-09-06T07:19:01Z

https://gitlab.haskell.org/ghc/ghc/issues/16130#note_220562

mpickering · 2019-09-06T09:33:08Z

@tscholak It looks like the channel that root is tracking is older than Feb 19th, can you try updating it to match your user channel?

tscholak · 2019-09-06T11:55:50Z

@mpickering oh, you are right, stupid me.

$ sudo nix-channel --update nixpkgs
$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 18.6.0, macOS 10.14.5`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.2.1`
 - channels(tscholak): `"nixpkgs-19.09pre191265.c4adeddb5f8"`
 - channels(root): `"nixpkgs-19.09pre191265.c4adeddb5f8"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

$ nix-build '<nixpkgs>' -A haskellPackages.text-format --check
...
installing
Installing library in /nix/store/1axayc02aym0m7lph2j96vmhvzg8dbmk-text-format-0.3.2/lib/ghc-8.6.5/x86_64-osx-ghc-8.6.5/text-format-0.3.2-3jozefXllK5KFJeZxJsPML
post-installation fixup
strip is /nix/store/jkwas56y5bpns1zmzr9mdcgqv9x9b5rx-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/1axayc02aym0m7lph2j96vmhvzg8dbmk-text-format-0.3.2/lib
patching script interpreter paths in /nix/store/1axayc02aym0m7lph2j96vmhvzg8dbmk-text-format-0.3.2
strip is /nix/store/jkwas56y5bpns1zmzr9mdcgqv9x9b5rx-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/0s8z7pqcvp33sc7560567l4jjpbm97rk-text-format-0.3.2-doc
warning: rewriting hashes in '/nix/store/gn727nbqiv3dszk929zlcqmvinrkgndk-text-format-0.3.2-doc'; cross fingers
warning: rewriting hashes in '/nix/store/60xj8p1qdcdlvs3khdvjg90rhnh275hv-text-format-0.3.2'; cross fingers
error: derivation '/nix/store/z6yf2bk00r9a096rfr5b0m8gk6ya0cfi-text-format-0.3.2.drv' may not be deterministic: output '/nix/store/60xj8p1qdcdlvs3khdvjg90rhnh275hv-text-format-0.3.2' differs

a little hiccup at the end, but the GHC bug is gone. cool.

tscholak · 2019-09-06T12:16:04Z

@mpickering @basvandijk @stites the renewed interest in this issue was prompted by a very similar GHC panic while building hasktorch on Darwin that pulls in a library called libtorch-ffi built with the c++ flag, see (https://github.com/hasktorch/hasktorch/blob/7105e865420037d92d11af69db1ec1ed163d20a9/nix/shared.nix#L105).

the error message is similar, but not exactly identical. have you ever seen this one:

ghc: panic! (the 'impossible' happened)
  (GHC version 8.6.5 for x86_64-apple-darwin):
        Data.Binary.Get.runGet at position 8: Invalid magic number "\202\254\186\190\NUL\NUL\NUL\STX"
CallStack (from HasCallStack):
  error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.6.0:Data.Binary.Get

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

builder for '/nix/store/bsq4mn07l3rki3zs2a895dvi3lj7nc5c-hasktorch-0.2.0.0.drv' failed with exit code 1

note here the difference: the invalid magic number is not INPUT(-l but rather \202\254\186\190\NUL\NUL\NUL\STX.

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?

tscholak · 2019-09-13T20:56:10Z

a tiny bit of progress with the above issue:

$ find /nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib/ -type file -print -exec sh -c "xxd -u {} | grep -e 'CA\s*FE\s*BA\s*BE\s*00\s*00\s*00\s*02' " \;
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_rt.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_intel_thread.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_blacs_mpich_lp64.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_intel_ilp64.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_vml_avx2.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libiompstubs5.a
00000000: CAFE BABE 0000 0002 0000 0007 0000 0003  ................
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_vml_avx.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_pgi_thread.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//locale/en_US/mkl_msg.cat
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_lapack95_lp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_mc.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_tbb_thread.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_core.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_vml_avx512.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libtbbmalloc.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_vml_mc.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_tbb_thread.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_avx.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libiomp5.dylib
00000000: CAFE BABE 0000 0002 0000 0007 0000 0003  ................
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_sequential.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_blas95_ilp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_cdft_core.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libiomp5_db.dylib
00000000: CAFE BABE 0000 0002 0000 0007 0000 0003  ................
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_scalapack_ilp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_blacs_mpich_ilp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_lapack95_ilp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_blacs_mpich_ilp64.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_cdft_core.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_core.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_blas95_lp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_mc3.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_intel_lp64.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_intel_lp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_scalapack_ilp64.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_intel_ilp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_scalapack_lp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_blacs_mpich_lp64.a
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_sequential.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_avx512.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_vml_mc2.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libtbbmalloc_proxy.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//license.txt
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libtbb.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libiomp5.a
00000000: CAFE BABE 0000 0002 0000 0007 0000 0003  ................
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_intel_thread.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_vml_mc3.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libiompstubs5.dylib
00000000: CAFE BABE 0000 0002 0000 0007 0000 0003  ................
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_scalapack_lp64.dylib
/nix/store/4fggrw8f06g3ryw4sya6nkv6hzzhi82j-mkl-2019.3.199/lib//libmkl_avx2.dylib

This comment has been minimized.

Sign in to view

ryantm added the 6.topic: haskell label Feb 16, 2019

matthewbauer added a commit to matthewbauer/nixpkgs that referenced this issue Feb 19, 2019

Revert "libcxx: add linker scripts for libc++.a to ensure libc++abi.a…

8cb7ea7

… is properly linked" This reverts commit 72e1764. This causes the GHC panic reported in issue NixOS#55848.

matthewbauer mentioned this issue Feb 19, 2019

Revert "libcxx: add linker scripts for libc++.a to ensure libc++abi.a… #56030

Merged

10 tasks

matthewbauer closed this as completed Apr 15, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GHC panic on darwin when building the static library of packages that depend on packages that link with libc++ #55848

GHC panic on darwin when building the static library of packages that depend on packages that link with libc++ #55848

basvandijk commented Feb 15, 2019

matthewbauer commented Feb 15, 2019

basvandijk commented Feb 15, 2019

matthewbauer commented Feb 15, 2019 •

edited

Loading

basvandijk commented Feb 15, 2019

basvandijk commented Feb 15, 2019

matthewbauer commented Feb 15, 2019

Twey commented Feb 16, 2019 •

edited

Loading

This comment has been minimized.

Twey commented Feb 16, 2019

Twey commented Feb 16, 2019

Twey commented Feb 16, 2019 •

edited

Loading

matthewbauer commented Feb 17, 2019 •

edited

Loading

matthewbauer commented Feb 19, 2019

basvandijk commented Feb 19, 2019

basvandijk commented Feb 25, 2019

matthewbauer commented Feb 25, 2019 •

edited

Loading

Twey commented Feb 25, 2019 •

edited

Loading

matthewbauer commented Feb 25, 2019 •

edited

Loading

Twey commented Feb 26, 2019 •

edited

Loading

MichaelXavier commented Apr 10, 2019

basvandijk commented Apr 15, 2019

MichaelXavier commented Apr 15, 2019

tscholak commented Sep 5, 2019 •

edited

Loading

idontgetoutmuch commented Sep 6, 2019

mpickering commented Sep 6, 2019

tscholak commented Sep 6, 2019 •

edited

Loading

tscholak commented Sep 6, 2019 •

edited

Loading

tscholak commented Sep 13, 2019 •

edited

Loading

GHC panic on darwin when building the static library of packages that depend on packages that link with libc++ #55848

GHC panic on darwin when building the static library of packages that depend on packages that link with libc++ #55848

Comments

basvandijk commented Feb 15, 2019

Issue description

Steps to reproduce

matthewbauer commented Feb 15, 2019

basvandijk commented Feb 15, 2019

matthewbauer commented Feb 15, 2019 • edited Loading

basvandijk commented Feb 15, 2019

basvandijk commented Feb 15, 2019

matthewbauer commented Feb 15, 2019

Twey commented Feb 16, 2019 • edited Loading

This comment has been minimized.

Twey commented Feb 16, 2019

Twey commented Feb 16, 2019

Twey commented Feb 16, 2019 • edited Loading

matthewbauer commented Feb 17, 2019 • edited Loading

matthewbauer commented Feb 19, 2019

basvandijk commented Feb 19, 2019

basvandijk commented Feb 25, 2019

matthewbauer commented Feb 25, 2019 • edited Loading

Twey commented Feb 25, 2019 • edited Loading

matthewbauer commented Feb 25, 2019 • edited Loading

Twey commented Feb 26, 2019 • edited Loading

MichaelXavier commented Apr 10, 2019

basvandijk commented Apr 15, 2019

MichaelXavier commented Apr 15, 2019

tscholak commented Sep 5, 2019 • edited Loading

idontgetoutmuch commented Sep 6, 2019

mpickering commented Sep 6, 2019

tscholak commented Sep 6, 2019 • edited Loading

tscholak commented Sep 6, 2019 • edited Loading

tscholak commented Sep 13, 2019 • edited Loading

matthewbauer commented Feb 15, 2019 •

edited

Loading

Twey commented Feb 16, 2019 •

edited

Loading

Twey commented Feb 16, 2019 •

edited

Loading

matthewbauer commented Feb 17, 2019 •

edited

Loading

matthewbauer commented Feb 25, 2019 •

edited

Loading

Twey commented Feb 25, 2019 •

edited

Loading

matthewbauer commented Feb 25, 2019 •

edited

Loading

Twey commented Feb 26, 2019 •

edited

Loading

tscholak commented Sep 5, 2019 •

edited

Loading

tscholak commented Sep 6, 2019 •

edited

Loading

tscholak commented Sep 6, 2019 •

edited

Loading

tscholak commented Sep 13, 2019 •

edited

Loading