Previously, we would set GHC_PACKAGE_PATH after configure, the reasons
being that

1. Setup.hs configure forbids this from being set since it can make a
   build fail that would otherwise succeed (since it influences how
   GHC behaves when invoked by Cabal).
2. Setting GHC_PACKAGE_PATH being set is sound in our case, since
   we set it precisely to the packages available to Cabal at configure
   time, so there should be no room for a mismatch.
3. Some test suites require GHC_PACKAGE_PATH or GHC_ENVIRONMENT to be
   set, so they can invoke GHC(i) with build dependencies available.
   Cabal >= 3.12 forbids GHC_PACKAGE_PATH from being set after
   <haskell/cabal@d6e38041a7c778fadf8f416>.
   Setting GHC_ENVIRONMENT would be possible, but is cumbersome without
   cabal-install (which has the handy cabal exec command which takes
   care of that). Additionally, it is not clear if it'll remain possible
   to do that: <haskell/cabal#7792>.

Our solution to Cabal 3.12's change is to be more targeted about setting
GHC_PACKAGE_PATH: We _just_ set it for the actual test suite executable.
This can be achieved by using --test-wrapper which when given is invoked
by Cabal to run the test suite. Here we can set any environment
variables after Cabal has already done its environment checks. As long
as we don't do anything stupid, this should be unproblematic.

Users can also arbitrarily influence what GHC_PACKAGE_PATH will contain
using the NIX_GHC_PACKAGE_PATH_FOR_TEST environment variable. This is
un(der)documented for now, since I want to keep some wiggle room for
changing stuff in the coming weeks. Also it's rarely necessary to
actually touch this variable.

elfutils is used in the RTS (rts/Libdw.c), i.e. it will be used on the
target platform.

Tested via pkgsCross.gnu32.haskellPackages.ghc [1], though #304605 needs
to be cherry-picked for elfutils to build.

[1]: nix-shell -E 'with import ./. { crossSystem = "i686-linux"; };
       mkShell { nativeBuildInputs = [haskellPackages.ghc ]; }'

Patches `crypton-x509-system` to use the full path to the `security`
binary.

This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.

See: #164630

Co-authored-by: sternenseemann <[email protected]>

This change ensures that packages won't be rebuild compared to before
the introduction of disallowedRequisites/disallowGhcReference unless
they use one of those arguments.

It may be nice to revert this in the future (via staging) for greater
simplicity, but will help with initial regression testing.

After 120f242, GHC_PACKAGE_PATH isn't
set implicitly in installPhase anymore. Instead we achieve the same by
telling the Makefile the exact ghc command line to use.

As a benefit, we can now cleanly separate build and host in this case:
We used to (implicitly) reuse the host package db. Now we can explicitly
request the package db also used for building Setup.hs.

It is somewhat curious that it behaves differently exclusively here, but
I don't think it is necessary to stop shipping a package due to floating
point arithmetic error—it would be unreasonable to assume there were
none…

See ekmett/ad#113.

This ports our infamous patch for Cabal that prevents certain parts of
the Paths_* module from being generated in order to prevent unnecessary
references on aarch64-darwin, to GHC >= 9.10.

See also:

- Original issues: #140774
- Patches
  - Original patch for GHC >= 8.10 && < 9.2 / Cabal >= 3.2 && < 3.6:
    b0dcd7f
  - Patch for GHC >= 9.2 && < 9.10 / Cabal >= 3.6 && < 3.12: #216857,
    f6f780f129f50df536fb30,
    …

Remove references to `hpack` and `distribution-nixpkgs` paths so that
`cabal2nix` can build on macOS.

See: #304352

I suspect that we'll be able to upgrade to 9.10.* for all three packages
after the next haskell-language-server update. I'll leave that to
maralorn.

Since emanote incurs a reference on GHC on all platforms this override
is all but uselless.

This matches what we do for GHC 8.10.7 where we also can't build the 9.6
versions.

This just requires picking the right version of the package for all
compiler versions.

elmPackages.elm: fix build failure on darwin

Fixes `cabal-install` to remove references to GHC, mostly through other
libraries that are included in the binary.

See: #304352

Co-authored-by: sternenseemann <[email protected]>

All these references would (indirectly) incur a GHC requisite which is
prevented by #304352 via justStaticExecutables. Consequently, we can
stop setting disallowedReferences.

As it turns out the references we were removing aren't currently
created, so our life gets even easier.

Since it incurs a GHC reference anyways, we have to disable
justStaticExecutables!

- Address some removals.
- Add all missing packages that use justStaticExecutables.

This commit disables justStaticExecutables for packages on
aarch64-darwin that incur a (usually incorrect) reference on GHC.
justStaticExecutables now fails when a GHC reference remains in the
output (#304352). Due to this reference justStaticExecutables (before
these changes) would only marginally reduce closure size.

In the future, we'll be able to re-introduce justStaticExecutables
after (manually) removing the incorrect references stemming from the use
of Paths_* modules. Tracking Issue: #318013