Sysroot build fails on Nix shell
DieracDelta opened this issue · 12 comments
I'm trying to use this tool in a nix shell. For some reason, it's sticking it in a write only directory (/tmp/nix-shell.NL1aJs/rustc-build-sysroot.6BErGTCriFwN). Could the sysroot directory be made configurable via flag or environment variable? I'm happy to implement if you'll pull it in :)
That is the temporary directory used for building. The actual sysroot should be put into the XDG cache directory (~/.cache/cargo-careful for me).
Are you saying your temp_dir does not work for writing and reading files? That sounds like a pretty broken or at least non-standard configuration to me, not sure how anything would work with that?
I am using https://crates.io/crates/tempdir for managing temporary build directories. That seems deprecated (so maybe I should switch to something newer), but it uses env::temp_dir(), which usually should be a readable and writeable directory. Something more fundamental seems to be wrong if that is not the case.
If you are getting build errors, could you share the full output?
You should be able to set a different tempdir by setting the TMPDIR env var. But I am still curious why the default would not work for you.
The full output:
$ cargo careful setup
Preparing a careful sysroot (target: x86_64-unknown-linux-gnu)...
error: failed to write /tmp/nix-shell.z96En4/rustc-build-sysroot.CJmRqR7HHqFF/Cargo.lock
Caused by:
failed to open: /tmp/nix-shell.z96En4/rustc-build-sysroot.CJmRqR7HHqFF/Cargo.lock
Caused by:
Permission denied (os error 13)
thread 'main' panicked at 'failed to build sysroot; run `cargo careful setup` to see what went wrong: sysroot build failed', src/main.rs:219:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
That's quite strange. For some reason cargo does not have write permissions to a directory that is writable for my user (I set TMPDIR, am quite certain I have write perms). It works as root. Hmm.
So somehow TMPDIR is not writable on your system? Hm... no the folder must be writeable, since the writing that cargo-careful itself does (to construct a workspace for cargo) works fine. It's only when starting cargo to do the sysroot build that things go wrong.
Maybe it is some kind of process isolation thing, where when a process starts sub-processes, those don't have access to the same TMPDIR? But that also sounds like it could break many things; starting sub-processes on previously prepared temporary files is a standard idiom on Unix and should be supported even on NixOS. Per-process /tmp is a thing but AFAIK it is usually inherited by child processes. (Is this NixOS? Some Nix seems to be involved. Nix is known to overthrow fundamental Unix/POSIX assumptions but not being able to prepare files for a subprocess in TMPDIR is going a bit too far IMO.^^ I don't think anything I am doing here is particularly un-idiomatic.)
Or maybe it is something else entirely, but I couldn't think of anything. Does it work if you set TMPDIR to something inside /home to avoid any special handling /tmp might receive?
I'm on a ubuntu machine with nix installed. So, not NixOS yet (though if I can get this to work I'm hoping to upstream!). I'm inside a nix-shell that has cargo-useful built and on my PATH. I've also got the RUST_LIB_SRC env var set correctly AFAICT.
I tried setting TMPDIR to a directory in my $HOME and still end up with the same error. I need to investigate further, but perhaps it's something related to running the execvp syscall inside nix shells..
I've also got the RUST_LIB_SRC env var set correctly AFAICT.
FWIW that shouldn't be needed, it will auto-detect the source folder of the active rustup toolchain. But also that can't really be the source of the problem anyway.
Hm... I had another idea for what this might be -- I distantly recall encountering something like that in the past, and then adding code like this to xargo. The lockfile is created by copying it from the lib source dir, and if that is for some reason read-only then those permissions might be copied to the new location. Turns out that fix in xargo came from a nix user. ;)
That still doesn't explain why so far nobody else seems to have seen this but it's more plausible than the other explanations.
@DieracDelta could you try the latest git version? It now explicitly disables "read-only" on the lockfile, which should hopefully fix your problem.
cargo install cargo-careful --git https://github.com/RalfJung/cargo-careful
That fixed it!! Thank you for your help! I'm quite excited to be using this on my projects :)
Related: upstreaming here
Great, thanks for reporting and testing. I'll ship a new release then. :)