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

Jump to bottom

stdenv: add armv7a-linux system #51628

Merged
merged 1 commit into from Mar 1, 2019
Merged

stdenv: add armv7a-linux system #51628

merged 1 commit into from Mar 1, 2019

Conversation

ju1m
Copy link
Contributor

@ju1m ju1m commented Dec 6, 2018

Motivation for this change

When building nix for ARM like this:

nix build nixpkgs.pkgsCross.armv7l-hf-multiplatform.nix

And installing it on a Cubieboard2, using #51626 .
One gets an "armv7a-linux" system, not an "armv7l-linux".

% nix-instantiate --eval -E "(import <nixpkgs> {}).system"
"armv7a-linux"

I don't know the difference, nor the meaning of this "a" (maybe "android"?),
which maybe comes from armv7l-hf-multiplatform.gcc.arch = "armv7-a" in lib/systems/platforms.nix.
This patch treats "armv7a-linux" like "armv7l-linux" in order to let nixpkgs find libc in nixpkgs:

% nix-instantiate --eval -E "(import <nixpkgs> {}).stdenv.cc.libc.name"
"glibc-2.27"
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • 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 nox --run "nox-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)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

Mic92
Mic92 reviewed Dec 6, 2018
View reviewed changes
pkgs/stdenv/linux/default.nix
@@ -13,6 +13,7 @@
"x86_64-linux" = import ./bootstrap-files/x86_64.nix;
"armv5tel-linux" = import ./bootstrap-files/armv5tel.nix;
"armv6l-linux" = import ./bootstrap-files/armv6l.nix;
"armv7a-linux" = import ./bootstrap-files/armv7l.nix;
Copy link
Member

Choose a reason for hiding this comment

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

I think this would also require the bootstrap tarball in question.

Copy link
Member

Choose a reason for hiding this comment

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

They're identical instruction sets. It should be safe to use these bootstrap tools for any version of armv7. In fact, I would argue that we shouldn't even provide armv7 bootstrap and instead use armv5 for all arm32 bootstrapping. Each new version of arm is a superset of the previous version. That's not the case with aarch64 as some CPUs don't support 32-bit mode.

@Ericson2314
Copy link
Member

We've flip-flopped between armv7a and arv7l. My guess is this has more to do with that than any intrinsic isuee / it's a statelessness bug.

@vcunat vcunat requested a review from dezgeg December 7, 2018 09:42
@lheckemann
Copy link
Member

ARMv7-A is the "Application" (profile?) of the ARM architecture, which I presume is what armv7a refers to. ARM also has big-endian and little-endian variations, so I presume the armv7l stands for little-endian. Both of these should be correct, although if something is looking for one where only the other exists that will be problematic.

@Ericson2314
Copy link
Member

Yes. I meant to also explain those but forgot. Thanks @lheckemann for doing that.

@dezgeg
Copy link
Contributor

dezgeg commented Dec 13, 2018

This isn't right. If compiling the same thing with cross results in armv7a when the one natively detected is armv7l, then the cross compiler definition in Nixpkgs is wrong and should be fixed instead of this change.

@matthewbauer
Copy link
Member

Could this actually be what was fixed in 50e947f?

@ju1m
Copy link
Contributor Author

ju1m commented Dec 14, 2018

Could this actually be what was fixed in 50e947f?

Thanks @matthewbauer, it's probably a better fix for this armv7a vs. armv7l mismatch.

To test it, I tried to build nix.binaryTarball again with this, and this is producing *-armv7l-unknown-linux-gnueabihf packages as expected. However I somehow was not able to test the install this time because ./install is failing when trying to run an x86-64 mkdir from coreutils.
This is because the resulting nix.binaryTarball is using closureInfo (which uses exportReferencesGraph) which unfortunately includes build time dependencies only runnable on the host (x86-64 in my case) like coreutils or those named armv7l-unknown-linux-gnueabihf-* which are required at build time by nix's propagatedBuildInputs: boehm-gc-7.6.6-armv7l-unknown-linux-gnueabihf.

I wish there were a way to tar only the runtime dependencies as wanted in NixOS/nix#1245
I've also tried to apply some patchelf --shrink-rpath as suggested in https://nixos.org/nixos/nix-pills/automatic-runtime-dependencies.html but to avail so far.

Hope I am not confusing you too much. It's slow to compile/test on my hardware, so I'm even slower than usual to wrap my head around this cross-compiling machinery.

@matthewbauer matthewbauer merged commit 9edb851 into NixOS:master Mar 1, 2019
@ju1m ju1m deleted the arm branch November 5, 2021 07:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@matthewbauer matthewbauer matthewbauer left review comments

@Mic92 Mic92 Mic92 left review comments

@Ericson2314 Ericson2314 Awaiting requested review from Ericson2314

@dezgeg dezgeg Awaiting requested review from dezgeg

Assignees
No one assigned
Labels
6.topic: stdenv Standard environment 10.rebuild-darwin: 0 10.rebuild-linux: 0
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
7 participants
@ju1m @Ericson2314 @lheckemann @dezgeg @matthewbauer @Mic92 @GrahamcOfBorg