haskellPackages: fix pkgsStatic on aarch64-darwin

[alexfmpe]

No clue why this was fine for x86_64-linux, but on aarch64-darwin, I got

$ nix-build -A pkgsStatic.haskell.packages.ghc910.ghc
configure: error: in `/nix/var/nix/builds/nix-16170-2790439639/ghc-9.10.3-source/_build/stage1/libraries/terminfo/build':
configure: error: curses library not found, so this package cannot be built

and after fixing that, in installPhase

# Fix the mode, in case umask is set
chmod 644 '/nix/store/07mbxqfbiim3chmrk5iy1qig8449rl1m-arm64-apple-darwin-ghc-9.10.3/lib/ghc-9.10.3/lib/package.conf.d/binary-0.8.9.3-3d56.conf'
'/nix/store/07mbxqfbiim3chmrk5iy1qig8449rl1m-arm64-apple-darwin-ghc-9.10.3/lib/ghc-9.10.3/bin/ghc-pkg' --global-package-db "/nix/store/07mbxqfbiim3chmrk5iy1qig8449rl1m-arm64-apple-darwin-ghc-9.10.3/lib/ghc-9.10.3/lib/package.conf.d" recache
if [ -d docs-utils ]; then \
	/nix/store/hf6y9njhfwvigr25kzrwmsvmv6jpni5n-coreutils-9.9/bin/install -c -m 755 -d "/nix/store/1503p0agvzgr8hcrgcv1f9cm344cxjfd-arm64-apple-darwin-ghc-9.10.3-doc/share/doc/arm64-apple-darwin-ghc/html/libraries/"; \
	/nix/store/hf6y9njhfwvigr25kzrwmsvmv6jpni5n-coreutils-9.9/bin/install -c -m 644 docs-utils/prologue.txt "/nix/store/1503p0agvzgr8hcrgcv1f9cm344cxjfd-arm64-apple-darwin-ghc-9.10.3-doc/share/doc/arm64-apple-darwin-ghc/html/libraries/"; \
	/nix/store/hf6y9njhfwvigr25kzrwmsvmv6jpni5n-coreutils-9.9/bin/install -c -m 755 docs-utils/gen_contents_index "/nix/store/1503p0agvzgr8hcrgcv1f9cm344cxjfd-arm64-apple-darwin-ghc-9.10.3-doc/share/doc/arm64-apple-darwin-ghc/html/libraries/"; \
fi
/nix/var/nix/builds/nix-51825-2701879890/ghc-9.10.3-source
ghc-settings-edit: /nix/store/07mbxqfbiim3chmrk5iy1qig8449rl1m-arm64-apple-darwin-ghc-9.10.3/lib/arm64-apple-darwin-ghc-9.10.3/lib/settings: openFile: does not exist (No such file or directory)

Notice the lines before the last refer to lib/ghc-9.10.3/ while settings is searched for in lib/arm64-apple-darwin-ghc-9.10.3

These issues are due to the discrepancies pointed out in #383165.
We have at least 3 layers to think about regarding what counts as "native" builds:

1. hostPlatform.canExecute targetPlatform
2. hostPlatform.config == targetPlatform.config
3. hostPlatform == targetPlatform

AFAICT, 3 implies 2 implies 1. We've mostly looked at 3, while ghc mostly looked at 2.
We might need to re-think things some in general, but changing common-hadrian.nix to use 2 instead of 3 in these places seems to be an improvement as it fixes pkgsStatic. Was able to build and run pkgsStatic.haskell.packages.ghc910.hello

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[wolfgangwalther]

I have similar changes on my local branch for darwin static support, but I have more changes in generic-builder, too. I believe there are more places where our builder differs from GHC in its judgement about "are we cross".

We might need more of these to build other packages than just hello, but we can do that later.

Will kick off another build here before merging.

[wolfgangwalther]

No clue why this was fine for x86_64-linux, but on aarch64-darwin,

It works for x86_64-linux, because the triple is not the same there - pkgsStatic uses musl, not glibc. You can get the same failure modes on x86_64-linux for pkgsMusl.pkgsStatic, which does musl native -> musl static cross.

[wolfgangwalther]

This fixes basic pkgsStatic on darwin, which works fine. Doing TemplateHaskell on darwin in the sandbox is still not working, but that's for later. We'll just need to allow local networking, I guess - it errors with:

iserv-proxy: Uncaught exception ghc-internal:GHC.Internal.IO.Exception.IOException:

Network.Socket.connect: <socket: 12>: permission denied (Operation not permitted)

[alexfmpe]

We'll just need to allow local networking, I guess

Annoyingly, I couldn't simply __darwinAllowLocalNetworking = true on iserv-proxy. It's the derivation that's ran that needs it, but since we don't know at eval time what needs TemplateHaskell, we'd always need to enable it for at least pkgsStatic on darwin.

Maybe I can relax that requirement via #445672 (comment). It wouldn't work for wine but don't think we need it there anyway.

[alexfmpe]

We might need more of these to build other packages than just hello, but we can do that later.

A lot of packages build with this change, including ones needing template-haskell.
Though some hit Failed to load dynamic interface file for <import>.
For instance, language-nix

[1 of 4] Compiling Language.Nix.Identifier ( src/Language/Nix/Identifier.hs, dist/build/Language/Nix/Identifier.o, dist/build/Language/Nix/Identifier.dyn_o )
src/Language/Nix/Identifier.hs:20:1: error: [GHC-47808]
    Failed to load dynamic interface file for Control.Lens:

Haven't noticed any other failures specific to "static cross" yet, but I'll wait for your local fixes until I poke around these parts again.
FYI building haskell-language-server is a pretty decent stress test as it has ~250 deps

[wolfgangwalther]

Haven't noticed any other failures specific to "static cross" yet, but I'll wait for your local fixes until I poke around these parts again.

Mine are not done and I haven't worked on them in a while, so don't wait for them. This was mostly taken out of #383165. I don't remember anymore where I hit other things exactly, they have possibly been fixed in the meantime in better ways or so.

If a lot of stuff is building, except for TH due to networking, that is a great sign.

[sternenseemann]

As I've stated before, in general, I'm not in favor of appeasing build systems in this manner. With the external interpreter, we did find a solution that, in particular, did not involve making hadrian believe we were natively compiling in order to get pkgsStatic to work, so we should really try to continue in this direction.

Especially matching on the config alone is an ugly hack that breaks the expectations of Nixpkgs users.

[alexfmpe]

we should really try to continue in this direction.

Fair enough, but how?
Are you saying we should instead backport the terminfo patch and unconditionally enable the target prefix?

[wolfgangwalther]

As I've stated before, in general, I'm not in favor of appeasing build systems in this manner.

I assume that was in #383165 - but the change proposed there was a lot different. That PR actually pretended native for the cross case, which is not the case here.

This PR has two changes:

• The change to the default value for enableTerminfo. The user can always override this. This also only extends the already existing hack, which has been fixed upstream for later versions - so this is going to go away in the future anyway.
• The change to targetPrefix. We already have a TODO there to make this unconditional. This means that any change that uses the targetPrefix in more cases than before is actually the right direction. (Edit: This logic is flawed, because this change actually uses the target prefix in fewer cases)

Thus, I think this PR is entirely fine.