Skip to content
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

[20.09] ghc:8.10.2Binary bootstrap for 8.8 on aarch64 (NixOS#97407) #101214 #102477

Merged
merged 3 commits into from Nov 2, 2020

Conversation

roberth
Copy link
Member

@roberth roberth commented Nov 2, 2020

Motivation for this change

Fix the GHC build on aarch64-linux. Backport of #101214

Refs #97407

Feel free to close if it's better merged via staging-20.09.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

sorki and others added 3 commits October 31, 2020 21:13
(cherry picked from commit 0d4f3ef)
Fixes:

utils/ghc-cabal/dist-install/build/tmp/ghc-cabal:
  error while loading shared libraries: libnuma.so.1:
    cannot open shared object file: No such file or directory

(cherry picked from commit b9377e0)
Copy link
Member

@cdepillabout cdepillabout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@roberth Thanks for backporting this.

I'm fine with merging this in as-is, but on the previous PR, @vcunat recommended that it should be merged into staging-next instead of master because there were a huge backlog of aarch builds on hydra.

However, as of right now, there are only 420 packages in the backlog for aarch64 (on https://hydra.nixos.org/queue-summary):

image

@vcunat Is this a lot? Or is 420 small? Can this be merged directly into release-20.09?

@roberth
Copy link
Member Author

roberth commented Nov 2, 2020

Oddly, the https://hydra.nixos.org/queue-summary page doesn't show me a row for aarch64-linux.
@vcunat Did it change for you?

I'm also seeing a lot of aborted build like this https://hydra.nixos.org/build/129460097, so I'm not sure if those builds can even succeed at this time.

@vcunat vcunat self-assigned this Nov 2, 2020
@vcunat
Copy link
Member

vcunat commented Nov 2, 2020

It's empty now. Partially thanks to many builds being blocked (including staging-next's llvm and thus ghc). So I guess it's convenient to utilize the window and binaries now, as ghc itself shouldn't be blocked by that Hydra problem.

On this commit the build seems OK – on the community machine (someone's cached it there already).

@vcunat vcunat merged commit 87ccb96 into NixOS:release-20.09 Nov 2, 2020
@roberth
Copy link
Member Author

roberth commented Nov 2, 2020

It seems to be ok. My build agent is currently 18 drvs away from cabal2nix so I'm quite confident about this PR. It's definitely an improvement over the current state.

vcunat added a commit that referenced this pull request Nov 2, 2020
Picked from master (part of 0ef1be0).  Needed after PR #102477.
@vcunat
Copy link
Member

vcunat commented Nov 2, 2020

OK, after fixing the missing maintainer it started to build: https://hydra.nixos.org/eval/1623733#tabs-unfinished

@vcunat
Copy link
Member

vcunat commented Nov 2, 2020

Aah right, I forgot to check... we're back at the "Output limit exceeded" problem: https://hydra.nixos.org/build/129491025

@roberth
Copy link
Member Author

roberth commented Nov 2, 2020

Stripping the docs and profiling from the bootstrapping compiler may work. #102504

The eventual compiler fits well within the limits.

@lostnet
Copy link
Contributor

lostnet commented Nov 4, 2020

@roberth It still seems to be around the 2gb limit(?), but I think *_p.a files are for profiling with static linking, are larger than the dynamic libraries and could be removed at the same time.

@roberth
Copy link
Member Author

roberth commented Nov 4, 2020

That's what I did in #102504 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants