-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
Cross-compiled NixOS #36187
Cross-compiled NixOS #36187
Conversation
No need to cross-compile pure data...
This involved: * Installing miniperl as $dev/bin/perl * Setting miniperl to take INC from lib/perl5/{site_perl/,}cross_perl/${version} as well as lib/perl5/{site_perl/,}/${version}/${runtimeArch}, in that order. miniperl taking from runtimeArch is not really correct, but it works in some pure-perl cases (e.g. Config.pm) and can be overridden with the cross_perl variant. * Installing perl-cross's stubs into $dev/lib/perl5/cross_perl/${version} * Patching MakeMaker.pm to gracefully degrade (very slightly) if B.pm can't be loaded, which it can't in cross-compilation. * Passing the right build-time and runtime perls to Makefile.PL
Also disable it when noXlibs in NixOS.
This is like stdenv.shell{,Package}, but for the runtime system. The majority of uses of stdenv.shell probably want this instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did something between a read and skim, and it looks all good so far!
@@ -130,6 +130,18 @@ in | |||
''; | |||
}; | |||
|
|||
crossSystem = mkOption { | |||
type = types.nullOr types.attrs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't let me forget about this when I return to #34444
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a similar value for localSystem? O:).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes if system
before is new in 18.03, it should be changed to local system instead. And the description of that config should in that case take into account crossSystem
: "for which NixOS should be built" isn't generally true, should be "on which".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be happy to do this in a follow-up PR though.
FWIW I just took a quick look at this as well and it's all pretty rote stuff, so I'm 👍 as well and excited to see these pieces making it in! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK reviewed all the nix stuff more thoroughly (didn't dive into every longer bash blob.)
pkgs/servers/dns/bind/default.nix
Outdated
@@ -24,6 +27,10 @@ stdenv.mkDerivation rec { | |||
|
|||
STD_CDEFINES = [ "-DDIG_SIGCHASE=1" ]; # support +sigchase | |||
|
|||
BUILD_CC = "cc"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also surprises me, I think the setup hook should also do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, will try again without these a bit later
pkgs/servers/dns/bind/default.nix
Outdated
@@ -13,6 +14,8 @@ stdenv.mkDerivation rec { | |||
sha256 = "10iwkghl5g50b7wc17bsb9wa0dh2gd57bjlk6ynixhywz6dhx1r9"; | |||
}; | |||
|
|||
preConfigure = "export AR=${stdenv.cc}/bin/${stdenv.cc.targetPrefix}ar"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's this about? Is the setup hook not working?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Permalink for posterity:
nixpkgs/pkgs/build-support/bintools-wrapper/setup-hook.sh
Lines 74 to 84 in 806edaa
for cmd in \ | |
ar as ld nm objcopy objdump readelf ranlib strip strings size windres | |
do | |
if | |
PATH=$_PATH type -p "@targetPrefix@${cmd}" > /dev/null | |
then | |
upper_case="$(echo "$cmd" | tr "[:lower:]" "[:upper:]")" | |
export "${role_pre}${upper_case}=@targetPrefix@${cmd}"; | |
export "${upper_case}${role_post}=@targetPrefix@${cmd}"; | |
fi | |
done |
(Sorry for the necro)
@@ -25,6 +25,10 @@ stdenv.mkDerivation rec { | |||
# Check that the udev plugin got built. | |||
postInstall = stdenv.lib.optional (udev != null) "[ -e $out/lib/dhcpcd/dev/udev.so ]"; | |||
|
|||
postFixup = '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add TODO for fixed patched shebangs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@Ericson2314 Fixed |
|
||
add_needed $1 | ||
|
||
while [ ''${#left[@]} -ne 0 ]; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I sometimes like while (( ''${#left[@]} )); do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Total approval now (don't really care about my one bash nit). Thanks again for doing this! Really nice whenever I see my cross work so bearing fruit.
Wow, great work! |
@shlevy: Can you show the Nix expression(s) you used to build the system in the screenshot? |
@bjornfor still have quite a bit of cleanup to do before "official" announcement, but https://github.com/shlevy/nixos-riscv-bootstrap/tree/589d1b3bb10909a268ada5d3542dbc844d086a92 (note that that repo has very little risc-v specific in it now and will be made more generic) |
Thanks! |
@@ -139,7 +139,7 @@ let | |||
|
|||
manual-combined = runCommand "nixos-manual-combined" | |||
{ inherit sources; | |||
buildInputs = [ libxml2 libxslt ]; | |||
nativeBuildInputs = [ buildPackages.libxml2 buildPackages.libxslt ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this need both nativeBuildInputs
and buildPackages
? Isn`t
nativeBuildInputs = [ libxml2 libxslt ];
enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dezgeg No, because the magic autoresolution for nativeBuildInputs essentially relies on being inside of a callPackage
d function (this is an oversimplification, but I don't think it's misleading in this context. @Ericson2314 ?). Because we simply have a top-level with pkgs
in this file, we don't get that benefit.
Note that we are working toward infrastructure that doesn't rely on the "splicing" hack that causes this behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, I see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's all correct.
@shlevy `pkgs.runtimeShell` vs. `stdenv.shell`. I'm confused. Why make another one?
Do you expect people to override `pkgs.runtimeShellPackage`? With what?
|
@oxij |
@oxij `stdenv.shell` is the shell used at *build* time. That need not be the same as the shell used by the newly-built NixOS, and indeed must not be for cross-compiled NixOS.
Why not simply `buildPackages.stdenv.shell` vs. `hostPackages.stdenv.shell` then?
|
But referring the successive (rather than previous) stages as in |
Also the notion of a "run-time shell" is arguably more of a NixOS one and nixpkgs one. You can see the only use in |
Ugh, wait.
You can see the only use in `pkgs` is to get around a `patchShebangs` bug.
Right, let's consider that
```
find $out -type f -print0 | xargs --null sed -i 's|${stdenv.shellPackage}|${runtimeShellPackage}|'
```
from `pkgs/tools/networking/dhcpcd/default.nix`.
I do understand that `stdenv.shellPackage` is magical here, but am I correct to assume that `stdenv.shellPackage = buildPackages.bash`, but `runtimeShellPackage = hostPackages.bash` (or `targetPackages.bash`?) in the above use case? Can't we simply replace that `runtimeShellPackage` with `pkgs.bash` (which is its definition) and get rid of it?
Also note that while you're right w.r.t. the only use of `runtimeShellPackage`, `grep -r runtimeShell` produces a whole lot of results.
And I'm confused when one is supposed to use `${pkgs.bash}/bin/bash` and when `pkgs.runtimeShell`. Are they not aliases? `pkgs.runtimeShell` is defined as an alias to `${pkgs.bash}/bin/bash`. Is there any magic here? Why do we even need `pkgs.runtimeShellPackage` and `pkgs.runtimeShell`? Most packages refer to `bash` via `${pkgs.bash}/bin/bash`, are they wrong in doing that?
|
I don't see any problems with referring to bash directly. I can't imagine the indirection buys us much. (If we ever get NixOS/nix#1080, that might be another matter, but we don't have it.) |
This includes a slew of fixes to get NixOS cross-compiling. Highlights:
ldd
(897b7c7)pkgs.runtimeShell
(e70f61f) and fixing NixOS scripts to use it (fec5434)