Fix GHC loadArchive clang++ error on macOS

[jkachmar]

Closes #149937.

Motivation for this change

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[jkachmar]

Note that I haven't tested this patch on GHC 8.8.4, 9.0.1, or 9.2.1.

I've only applied it to those expressions following IOHK's guidance (as they apply this patch in their repository to all versions of GHC following 8.6.4).

---

EDIT: If possible I would really appreciate it if we could back port this to earlier versions of nixpkgs (21.11 at a minimum, but 21.05 would also be wonderful).

I was bitten by it on x86_64-darwin before (but I wasn't sufficiently motivated to track down a solution at the time); today I ran into it again on aarch64-darwin now that I'm trying to use nixpkgs with one of the new M1 MacBook Pros.

[jkachmar]

@bgamari made the following observation when we discussed this in another channel:

Oof, that c++ issue is rather frustrating since it's arguably a workaround for a linker bug which may break currently-working programs

If I understand correctly this patch will break users who specify, e.g., extra-libraries: z in their cabal file

I think a more correct way to work around this bug would be to incorporate a check to ensure that we aren't trying to link against an executable

[cdepillabout]

If I understand correctly this patch will break users who specify, e.g., extra-libraries: z in their cabal file

@jkachmar Were you able to figure out if this is the case?

If so, it sounds pretty bad? My guess is that there are quite a few packages using extra-libraries (although I'm not actually that sure).

Also, most of the Haskell maintainers (other than sternenseemann) don't use darwin as far as I know, so we might have to ping @ NixOS/darwin-maintainers in order to get this reviewed.

[jkachmar]

I looked into this a bit more again tonight and I still don't really know what the best path forwards is here.

Some related issues:

• Darwin build error - ghc: loadArchive: neither an archive, nor a fat archive tweag/rules_haskell#1601 (comment)
• Support for compilers and build tools in profiles #42059
• https://gitlab.haskell.org/ghc/ghc/-/issues/16590

---

@jwiegley I saw that you opened the GHC issue linked above; did you ever find a satisfactory workaround to the issue (or was it resolved for you in an updated GHC release)?

[mariatsji]

Thanks, this patch solved the problem I was having with cabal build in a nix-shell using GHC 8.10.7 on darwin:

ghc: loadArchive: Neither an archive, nor a fat archive: `/nix/store/cvz17hkb0wpbsyx58l4zcaamqs2bhlmz-clang-wrapper-11.1.0/bin/clang++'
ghc: panic! (the 'impossible' happened)
  (GHC version 8.10.7:
        loadArchive "/nix/store/cvz17hkb0wpbsyx58l4zcaamqs2bhlmz-clang-wrapper-11.1.0/bin/clang++": failed

[ghost]

A bit surprised this is still not fixed. Can't build cabal-install on darwin because of that. :(

[sternenseemann]

As stated above, the workaround is not satisfactory, as it may break legitimate use cases that are already working today.

Building cabal-install on darwin is unaffected by this issue:

• https://hydra.nixos.org/job/nixpkgs/nixpkgs-unstable-aarch64-darwin/cabal-install.aarch64-darwin
• https://hydra.nixos.org/job/nixpkgs/trunk/cabal-install.x86_64-darwin

[jkachmar]

i agree that this solution is unsatisfactory, however as far as i can tell "something" does need to be done to address this. i'm fine with closing this PR, but i hesitated to do so because it has more activity (and more context) than the discussion at #149937.

if anyone has any ideas for how we should fix this, i'd be more than willing to dedicate some time to exploring them and patching things properly.

[maksar]

iohk repo doesn't have a patch for ghc944. Structure of the files has changed in GHC. I used this patch and can confirm issue disappeared:

--- a/compiler/GHC/Linker/Loader.hs
+++ b/compiler/GHC/Linker/Loader.hs
@@ -1616,8 +1616,6 @@
        | verbatim = [lib]
        | otherwise = [ "lib" ++ lib ++ lib_tag <.> "a"
                      , lib <.> "a" -- native code has no lib_tag
-                     , "lib" ++ lib
-                     , lib
                      ]
      lib_tag = if is_hs && loading_profiled_hs_libs then "_p" else ""

[sternenseemann]

@maksar This is equivalent to the patch proposed in this PR and as mentioned above, GHC upstream thinks that the patch breaks legitimate use cases.

[harryaskham]

Experiencing the same issue with GHC 9.8.1 on nix-darwin, tried with gcc/clang from each of OSX and nixpkgs in the path. I'll see if patching still works following e.g. e9d090f

[maksar]

@harryaskham JFYI we are still using this patch on 9.8.2 and it helps on darwin and doesn't hurt on linux.