-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
stdenv Rust fixes #268168
stdenv Rust fixes #268168
Conversation
d4fb336
to
905f288
Compare
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 agreed this seems strictly better.
FWIW this works fine with a package that I maintain that depends on |
905f288
to
3a38b49
Compare
took a while to build, but |
3a38b49
to
3df2182
Compare
@Ericson2314 can I get your ack for dropping the assertion that at most one of "rust" and "rustc" is given? Caused eval to fail; reason now explained in the first commit message. |
# https://github.com/rust-lang/rust/blob/2e44c17c12cec45b6a682b1e53a04ac5b5fcc9d2/src/bootstrap/config.rs#L415-L421 | ||
isNoStdTarget = | ||
builtins.any (t: lib.hasInfix t final.rust.rustcTarget) ["-none" "nvptx" "switch" "-uefi"]; | ||
}; |
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.
}; | |
} // (args.rust or {}); |
Otherwise people have no way to override any of this stuff without editing this file.
Previously // args
was the last thing in the //
-chain, which provided an escape hatch.
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 don't think that works. If you pass { rust.platform = { arch = …; os = …; }; }
, target-family
is supposed to be filled in automatically. If we did a merge like this at the end, the whole platform
attrset would be overridden with just the values you passed, so target-family
wouldn't end up being there.
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'm also not confident that this needs to be supported, at least not right now. It was never supported when these were in rust.lib, except by using an overlay, which you could also use in this situation. It would be a bit ugly, but making workarounds for things be ugly when they're fixable bugs in the underlying code is not the worst thing, because it encourages fixing the thing rather than working around it.
@ofborg eval |
3df2182
to
6846d96
Compare
Usually, attributes passed explicitly to elaborate take precedence over the elaborated ones, but since we also elaborate the nested "rust" attrset, we need to push that one level down, so the rest of "rust" is still filled in if you just pass { rust = { config = ... } }. I've had to drop the assertion that checked that at most one of "rust" and "rustc" was part of the un-elaborated system, because doing this broke passing an elaborated system in, which should be idempotent. For the same reason, I've also had to make it possible for rust.rustcTargetSpec to be passed in. Otherwise, on the second call, since platform was filled in by the first, the custom target file would be constructed. The only other way to avoid this would be to compare the platform attrs to all built in Rust targets to check it wasn't one of those, and that isn't feasible. Fixes: e3e57b8 ("lib.systems: elaborate Rust metadata")
The previous version stopped working when we started elaborating Rust metadata. Here, I've made it a bit nicer by actually setting targetPlatform to an elaborated system. Setting the config to wasi to get elaborate to understand it is a bit of a hack, but I think it's less of a hack than what we had before. The only actual difference this makes to the rustc-wasm32 derivation compared to the previous working version, is that now crt-static is set. This is probably the right thing anyway. Fixes: e3e57b8 ("lib.systems: elaborate Rust metadata")
6846d96
to
886c892
Compare
Also had to make it possible to pass in |
Pardon the question, but what is left to get this merged? |
I would still like @Ericson2314's ack for the changes I mentioned. |
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'm currently running this patchset to fix lldap for my deployments.
IMO we should merge this as-is. It's strictly better than the current situation, since there are broken packages depending on this fix, and if @Ericson2314 has any concerns they can be addressed in a follow-up PR. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Successfully created backport PR for |
This change broke rustc on armv7l-linux and riscv64-linux when evaluating with NixOS system:
Used commands: git bisect start
git bisect good 19cbff5
git bisect bad e92039b55bcd
git bisect run nix-build nixos -A pkgs.rustc --argstr system riscv64-linux -I nixos-config=test.nix --dry-run
{
boot.loader.grub.device = "/dev/sda";
fileSystems."/".device = "/dev/sda1";
services.sshd.enable = true;
} See #271000 for more info |
Description of changes
See commit messages. Fixes a couple of regressions from #233628.
wasm32-rustc is still not ideal. As followup, I'd like to investigate whether we could just always include the wasm32-unknown-unknown target in rustc builds, since it doesn't require any libc dependency or anything.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)