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.
Ericson2314
left a comment
There was a problem hiding this comment.
I did something between a read and skim, and it looks all good so far!
| }; | ||
|
|
||
| crossSystem = mkOption { | ||
| type = types.nullOr types.attrs; |
There was a problem hiding this comment.
Don't let me forget about this when I return to #34444
There was a problem hiding this comment.
Can we have a similar value for localSystem? O:).
There was a problem hiding this comment.
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.
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! |
Ericson2314
left a comment
There was a problem hiding this comment.
OK reviewed all the nix stuff more thoroughly (didn't dive into every longer bash blob.)
pkgs/servers/dns/bind/default.nix
Outdated
|
|
||
| STD_CDEFINES = [ "-DDIG_SIGCHASE=1" ]; # support +sigchase | ||
|
|
||
| BUILD_CC = "cc"; |
There was a problem hiding this comment.
This also surprises me, I think the setup hook should also do this.
There was a problem hiding this comment.
There was a problem hiding this comment.
There was a problem hiding this comment.
Hmm, will try again without these a bit later
pkgs/servers/dns/bind/default.nix
Outdated
| sha256 = "10iwkghl5g50b7wc17bsb9wa0dh2gd57bjlk6ynixhywz6dhx1r9"; | ||
| }; | ||
|
|
||
| preConfigure = "export AR=${stdenv.cc}/bin/${stdenv.cc.targetPrefix}ar"; |
There was a problem hiding this comment.
What's this about? Is the setup hook not working?
There was a problem hiding this comment.
There was a problem hiding this comment.
There was a problem hiding this comment.
Permalink for posterity:
nixpkgs/pkgs/build-support/bintools-wrapper/setup-hook.sh
Lines 74 to 84 in 806edaa
(Sorry for the necro)
| # 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.
Add TODO for fixed patched shebangs?
|
@Ericson2314 Fixed |
|
|
||
| add_needed $1 | ||
|
|
||
| while [ ''${#left[@]} -ne 0 ]; do |
There was a problem hiding this comment.
I sometimes like while (( ''${#left[@]} )); do
Ericson2314
left a comment
There was a problem hiding this comment.
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! |
| manual-combined = runCommand "nixos-manual-combined" | ||
| { inherit sources; | ||
| buildInputs = [ libxml2 libxslt ]; | ||
| nativeBuildInputs = [ buildPackages.libxml2 buildPackages.libxslt ]; |
There was a problem hiding this comment.
Why does this need both nativeBuildInputs and buildPackages? Isn`t
nativeBuildInputs = [ libxml2 libxslt ];
enough?
There was a problem hiding this comment.
@dezgeg No, because the magic autoresolution for nativeBuildInputs essentially relies on being inside of a callPackaged 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.
|
@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)