error: linker cc not found

[mdedetrich]

Not sure if this is a duplicate of #22

When using the stable rust overlay, i.e.

nix-env -iA nixos.latest.rustChannels.stable.rust

I get the following error

cargo install racer
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing racer v2.0.12
   Compiling lazy_static v0.2.11
   Compiling unicode-xid v0.0.3
   Compiling utf8-ranges v0.1.3
   Compiling term v0.4.6
   Compiling bitflags v0.7.0
   Compiling vec_map v0.8.0
   Compiling cfg-if v0.1.2
   Compiling unicode-width v0.1.4
   Compiling bitflags v1.0.1
   Compiling libc v0.2.37
   Compiling regex-syntax v0.3.9
   Compiling strsim v0.7.0
   Compiling winapi-build v0.1.1
   Compiling ansi_term v0.10.2
   Compiling rustc-serialize v0.3.24
   Compiling winapi v0.2.8
   Compiling log v0.4.1
   Compiling textwrap v0.9.0
   Compiling kernel32-sys v0.2.2
error: linker `cc` not found
  |
  = note: No such file or directory (os error 2)

error: aborting due to previous error

error: Could not compile `kernel32-sys`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `racer v2.0.12`, intermediate artifacts can be found at `/tmp/cargo-install.fUBCOollQMQy`

Caused by:
  build failed

It seems like gcc is not really visible to rustc. I tried the variant noted in the other issue i.e. nix-env -iA nixos.latest.rustChannels.stable.rust -p gcc and it made no difference.

Here are the details of my nix install

system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(root): "nixos-17.09.3083.87c057a9c16", channels(mdedetrich): "", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

[garbas]

@mdedetrich can you try this with nix-shell (not nix-env)?

[mdedetrich]

Ah yes, it works with nix-shell however I am not sure how you would then persist the installation of rust using nix-shell (sorry I am bit new with nixos and I am figuring it out still).

Using nix-shell I can't actually get rust to work with IDE's like Visual Studio Code

[garbas]

could you run code from within the nix-shell? this is how i usually work in certain environments, but i do use vim and not vscode.

[mdedetrich]

True this should work meantime, is there a more permanent solution that doesn't use nix-shell or is this just how people are using Rust in nixos for the meantime?

[garbas]

I'm not sure how everybody is using nix but my workflow is exactly like that. i rarely use nix-env. mostly i'm just using nix-shell to enter the development environment of some project.

the only time i use nix-env is when i'm using already released applications (eg firefox) and not for development.

I think this is a shift in thinking how to setup development environment with nix and with other more traditional package managers. with traditional package managers you would pollute your system and install packages witch may even conflict with other packages already installed. and with nix you can have unlimited set of development environments just by using nix-shell.

I hope this helps a bit. I will close the issue since it looks like using nix-shell is the right way to do it. but please reopen if you disagree. If you still have some questions how to use nix etc... we can keep the conversation also here.

[mdedetrich]

@garbas I would vouch for keeping this ticket open, not because of your argument where nix-shell should be your desired workflow but because the documented workflow doesn't work. i.e. if you install rust via nix-env, the package should work out of the box, regardless of whether nix-shell should be the desired workflow (or not). Installing rust this way is even what is documented on the nixos wiki, i.e. look at https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/rust.md#using-the-rust-nightlies-overlay

In any case, I don't know if the statement that you should use nix-shell over nix-env is completely correct, at least with all of the nixOs documentation everyone says to use nix-env, and the only thing that nix-env does is put packages in a config under a profile in the exact same way that /etc/nixos/configuration.nix works, its just as part of your profile.

Furthermore there may be some discrepancy where for programming development you should also be using nix-shell instead of nix-env, but in any case the rust package in the mozilla overlay is actually not working as described when using nix-env, which means it should be a bug. Not only this, but some IDE's don't work so well with this approach because in in nix-shell your environment variables are hard linked to the actual location, i.e. if you use Intellij IDEA you typically have to specify folders for dependencies (rather than it looking in path). If you use nix-env all of your libraries (i.e. rust src or JDK in the case of Java) are symlinked in ~/.nixprofile where as with nix shell you have to manually find the hashed location of some folder where your libraries are located. nix-shell works fine for editors that look up everything via a path, but not editors where you have to manually specify locations of folders.

In any case there hasn't been anything I have seen (from reading the nixOs wiki) which says that you should always use nix-shell, from what I have seen its up to the users discretion, in some cases nix-shell makes more sense and in others it doesn't.

I can't reopen the ticket, but I would reopen it for this reason. Its expected that if you install a package (whether its using nix-shell or nix-env) that it works out of the box, and this isn't the case. If you use nix-env to install rust, then simply put you can't compile anything because you are missing gcc, this isn't what I would call expected user behavior.

[fkarg]

For the sake of completeness: it also simply works when adding the gcc-package, regardless of intended workflow.

[Apteryks]

I had this issue in GNU Guix as well, trying to bootstrap Rust 1.29.2. It turns out that the issue is src/librustc_codegen_llvm/back/link.rs, which looks for cc on the PATH. The exact line is this one: LinkerFlavor::Gcc => "cc".as_ref(). One would think that if it already figured out the flavor is GCC, it'd use gcc.