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

spidermonkey_68: fix build on armv7l #86532

Closed

Conversation

thefloweringash
Copy link
Member

Motivation for this change

Build fix.

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.

// emulation here.

-#if defined(__linux__) && defined(__arm__)
+#if 0
Copy link
Member

Choose a reason for hiding this comment

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

Could we not check for __ANDROID__? It would make it clearer what’s going on, and mean that if somebody (in theory) built this for Android they’d get the right thing.

@@ -17,6 +17,13 @@ in stdenv.mkDerivation rec {
outputs = [ "out" "dev" ];
setOutputFlags = false; # Configure script only understands --includedir

patches = optionals stdenv.isAarch32 [
Copy link
Member

Choose a reason for hiding this comment

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

Applying patches conditionally is an anti pattern because they bit rot.

Copy link
Member

@arcnmx arcnmx Jun 3, 2021

Choose a reason for hiding this comment

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

While true, I feel like there's an argument to be made for avoiding dirtying derivations on platforms that do not need the patch, avoiding the usual staging churn, useless recompiles, etc. It's not like it's a used codepath on those platforms, so the patch could still bitrot even if it applies cleanly! I'd be surprised if this isn't pulled in as part of some obscure hydra job anyway?

@arcnmx
Copy link
Member

arcnmx commented Jun 1, 2021

The build for 78 is still broken and also seems to need this patch applied.

@thefloweringash
Copy link
Member Author

The build for 78 is still broken and also seems to need this patch applied.

There's a PR for that too: #114942. The patch there is slightly different. We should choose one approach and apply it to both versions.

@arcnmx
Copy link
Member

arcnmx commented Jun 3, 2021

Not that I care much but I'd be inclined to just go with the debian patch? either way yeah +1 for consistency

@stale
Copy link

stale bot commented Jan 9, 2022

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 9, 2022
@lostnet
Copy link
Contributor

lostnet commented Feb 2, 2022

spidermonkey_68 is now removed: #153451

@lostnet lostnet closed this Feb 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 10.rebuild-darwin: 0 10.rebuild-linux: 0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants