How to override stdenv?

[burdiyan]

trafficstars

I wonder if it's possible to override stdenv when using this overlay?

The problem I'm having has to do with the fact that this overlay uses propagated buildInputs in various places to propagate cc from stdenv. In the project I'm working on I use different cc, but I'm not able to override cc for this overlay no matter what I try, and it override my own cc version in my nix-shell, and everywhere else I depend on rust from this overlay.

Is there any way to override stdenv here?

[oxalica]

The CC is used by rustc as a linker. You could set cargo configurations to overide it. The default name (gcc on Linux) seems to be fixed in rustc and is hard to patch.

[bjornfor]

Before I saw this issue, I made a wrapper derivation to work around the stdenv propagation. I haven't hit an issue yet (but who knows, is this unsafe?).

  # Create a wrapper that only exposes $pkg/bin. This prevents pulling in
  # development deps, like python interpreter + $PYTHONPATH, when adding
  # packages to a nix-shell. This is especially important when packages
  # are combined from different nixpkgs versions.
  mkBinOnlyWrapper = pkg:
    pkgs.runCommand "${pkg.pname}-${pkg.version}-bin" { inherit (pkg) meta; } ''
      mkdir -p "$out/bin"
      for bin in "${pkgs.lib.getBin pkg}/bin/"*; do
          ln -s "$bin" "$out/bin/"
      done
    '';

And then using it like this:

  nativeBuildInputs = [
    ...
    # Use mkBinOnlyWrapper to avoid propagating stdenv.cc, so we can
    # customize the stdenv with mkShell.override { stdenv = ...; }
    (mkBinOnlyWrapper rust-bin.stable."1.60.0".default)
  ];

[burdiyan]

I solved this by adding another level of indirection too :)

I re-exported rust from this overlay into my own overlay, replacing the propagated dependencies like so:

rust-stable = (super.rust-bin.stable.latest.default.overrideAttrs (oldAttrs: {
    propagatedBuildInputs = [];
    depsHostHostPropagated = [];
    depsTargetTargetPropagated = [];
  }));

[steveej]

@burdiyan would be great to see a full example of how that snippet fits into overriding stdenv for a rust derivation. in my case i'm trying to get buildRustPackage to use clang v14 on linux and darwin, so far something's always overriding what i'm trying to do.

[burdiyan]

@steveeJ I'm using Nix purely for nix-shell with direnv. So I'm not actually using it for building my own derivation. So, by using the overlay snipped I posted I at least get it rust-overlay to not override the cc from the stdenv, and it seems to work for me. Actually, what I'm doing on macOS is to overwrite the cc to use the one from the system. I have an impure-cc derivation that symlinks system paths to the Nix store, and I use that as my C toolchain. It's good enough for my development environment purposes.

[steveej]

thanks @burdiyan. is the final effect that cargo build will use CC from your system? do you also change something in the project's Cargo.toml? i'm asking because i see this happening in nixpkgs's build-support/rust/hook.

[burdiyan]

@steveeJ yes, the final effect is that in my development shell the CC is exposed from my impure-cc thing, which is also what cargo build ends up using (I guess, otherwise it would pick up my system-wide toolchain, which is what I want anyway :))