After installing rust via rustup (installed via nix-shell or nix-env), trying to build even a simple hello world rust program results in error[E0463]: can't find crate for 'std'
I performed these tests on nixpkgs commit 6d599b791ec5d04504b90743447c23d3d23e10fc, which is the latest commit as I am writing this.
[mythmon@gallium:~]$ nix-shell --pure -p rustup
[nix-shell:~]$ BASE=/tmp/rustup-test-$$
[nix-shell:~]$ export RUSTUP_HOME=$BASE
[nix-shell:~]$ export CARGO_HOME=$BASE
[nix-shell:~]$ mkdir $BASE
[nix-shell:~]$ cd $BASE
[nix-shell:/tmp/rustup-test-9987]$ rustup toolchain list
[nix-shell:/tmp/rustup-test-9987]$ rustup toolchain install stable
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
stable-x86_64-unknown-linux-gnu installed - rustc 1.17.0 (56124baa9 2017-04-24)
[nix-shell:/tmp/rustup-test-9987/test_project]$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
[nix-shell:/tmp/rustup-test-9987]$ rustup default stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.17.0 (56124baa9 2017-04-24)
[nix-shell:/tmp/rustup-test-9987]$ cargo new --bin test_project
Created binary (application) `test_project` project
[nix-shell:/tmp/rustup-test-9987]$ cd test_project
[nix-shell:/tmp/rustup-test-9987/test_project]$ cargo run
Compiling test_project v0.1.0 (file:///tmp/rustup-test-9987/test_project)
error[E0463]: can't find crate for `std`
error: aborting due to previous error
error: Could not compile `test_project`.
To learn more, run the command again with --verbose.
I can agree to this problem (using 17.09pre106299.7f3b857d0d (Hummingbird))
Yeah, unfortunately it is still broken. So what I did to run the unmodified toolchain, was to patch rustup to always to pass the executable as first argument to ld-linux-x86-64.so.2 to avoid the use of patchelf. This worked well, however rust internally uses /proc/self/exe to find where its toolchain lives. Usually this works as rustc is the target of the /proc/self/exe symlink. However in our case it is the link loader ld-linux-x86-64.so.2 outside of ~/.rustup. This is why everything breaks horrible. A hack around it, would be to copy ld-linux-x86-64.so.2 to ~/.rustup/toolchains/<toolchain>/bin.
I probably will mark this as broken or remove it again from nixpkgs, so other people will not waste their time and use the other options to install rust.
What I do in my project. I've added this line to my default.nix shellHook:
export RUSTFLAGS="-L $HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/"
I don't really like this hardcoded way, but I at least I can use rustup.
Also @Mic92 please don't remove it, or at least leave some way of installing it :) For me it is way easier to use rustup for nightly compiler, even with this workaround (my project requires nightly).
oh, good idea. This would be a less uglier workaround, which could be integrate into rustup.
For rust and Nixos I would propose to use the rust-overlay https://github.com/mozilla/nixpkgs-mozilla
Then you don't have to play any environment variable tricks :)
it does not address cross-compilers if I remember correctly.
@Mic92 I wasn't able to get cross compiling working. I've tried to compile musl target.
I meant nixpkgs-mozilla.
I have a pull request open for cross compilation support(https://github.com/mozilla/nixpkgs-mozilla/pull/24).
For anybody who has ended up here while trying to figure out how to get Xargo working; you'll want to have a look at mozilla/nixpkgs-mozilla#51, which includes a workaround.
Any progress here?
I'm currently getting two rustup related issues. The one discussed in this thread and https://github.com/rust-lang-nursery/rustup.rs/issues/1062 which seems to be fixed in newer versions of rustup.
To note, the latest version of rustup at the time of writing is 1.9.0. Nixpkgs has 1.3.0.
Did you tried the overlay? I'm using it for cross compilation.
Overlay works fine but no rustup there.
Why do you need rustup? Rustup defeats the purpose of Nixpkgs/NixOS(yeah I know, the overlay is also not standard compliant).
Convinence mostly. Being able to script around rustup and have it work on multiple platforms.
Yeah, that will be complicated on Nixos. The main problem is, that you would need to run patchelf manually on the downloaded toolchain.
I'm currently updating rustup and will send a pull request in the next hour, I hope that fixes some of your problems.
Are you talking about stable? Because on unstable rustup works correctly.
I'm talking about nixos-17.09, if that's what you refer by stable.
If you could test if cbe326feb88c380dbee2a9b500fd32a307f71cf6 works correctly on 17.09, I can back port this patch.
@Mic92 a quick test today seemed to work alright using the nixpkgs master branch. Can't tell about cross compiling though. Thanks for the effort
backported in b1be17c5870ce5e7f1b4ba29f7ede260ce3ae8b0
@bkchr I'd like to experiment with rust for wasm and raspberry on nixos. What is currently best way of compiling for those targets?
I think you should use the Mozilla nix overlay.
(latest.rustChannels.nightly.rust.override { extensions = [ "rust-src" ]; targets = [ "wasm-unknown-linux-unknown" ];})
That should give you a rust with all the things you need :) (I'm unsure if the target name is correct, but it print a list of available targets if something is not correct)
Rustup also worked for me when I compiled for the musl target. So both the overlay and rustup should be ok.
I think this issue was solved.