$CC incorrectly set to cross-compiler when rustToolchain and cross-compiler coexist in mkShell

[PeterWang-dev]

Problem

When using mkShell with both a Rust toolchain and a cross-compiler for a different target (e.g. riscv32), $CC is incorrectly set to the cross-compiler instead of the native compiler.

This is a common scenario for embedded/simulator development where you need:

• A Rust toolchain to build the simulator (native, x86_64)
• A cross-compiler to build test programs (target, e.g. riscv32)

Minimal Reproduction

# shell.nix
let
  pkgs = import (fetchTarball "https://nixos.org/channels/nixos-25.11/nixexprs.tar.xz") {};
  pkgsOverlay = pkgs.appendOverlays [
    (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
  ];
in pkgs.mkShell {
  packages = [
    pkgsOverlay.rust-bin.stable.latest.default    # Rust toolchain for the simulator
    pkgs.pkgsCross.riscv32.buildPackages.gcc       # Cross-compiler for test programs
  ];
}

$ nix-shell --pure shell.nix --run 'echo "CC=$CC CC_FOR_BUILD=$CC_FOR_BUILD"'
CC=riscv32-unknown-linux-gnu-gcc CC_FOR_BUILD=gcc
# Expected: CC=gcc, or at least CC_FOR_BUILD should be the cross-compiler

Without rustToolchain in packages:

CC=gcc CC_FOR_BUILD=
# Correct

Without cross-compiler in packages:

CC=gcc CC_FOR_BUILD=
# Correct

Analysis (AIGC, but seems correct)

The root cause is in lib/mk-aggregated.nix:

# Workaround: should be `pkgsHostHost.cc` but `stdenv`'s cc itself have -1 offset.
depsHostHostPropagated = [ stdenv.cc ];

This writes the native gcc into propagated-host-host-deps. During setup.sh's findInputs, when processing the rust toolchain's propagated dependencies, the offset math causes the native gcc to be registered with targetOffset=-1 (BUILD role, setting CC_FOR_BUILD=gcc). Later, defaultNativeBuildInputs tries to register the same native gcc with targetOffset=0 (HOST role, which would set CC=gcc), but findInputs's deduplication skips it because the store path is already registered. The cross-compiler's setup-hook (which sets CC=riscv32-...-gcc) is therefore left unoverridden.

Environment

• nixpkgs: nixos-25.11
• rust-overlay: master (current as of 2026-04-25)
• Host: x86_64-linux

[oxalica]

packages = [
pkgsOverlay.rust-bin.stable.latest.default # Rust toolchain for the simulator

Compilers goes nativeBuildInputs, not buildInputs (packages is an alias for buildInputs, for "easy use", as they thought). There is a dedicate README for cross-compilation which covers it at docs/cross_compilation.md. Please read existing docs first before trusting any AIGC.

Analysis (AIGC, but seems correct)

The root cause is in lib/mk-aggregated.nix:

The code you quoted has a comment explaining the exact reason why it should be like this. rustc is the compiler and its host platform is your package's build platform, ie. an implicit -1 offset. The AIGC is trying to make it "fixed" under the incorrect using pattern, and break the correct using pattern.

[PeterWang-dev]

@oxalica Thanks for your quick reply!

packages = [
pkgsOverlay.rust-bin.stable.latest.default # Rust toolchain for the simulator

Compilers goes nativeBuildInputs, not buildInputs (packages is an alias for buildInputs, for "easy use", as they thought). There is a dedicate README for cross-compilation which covers it at docs/cross_compilation.md. Please read existing docs first before trusting any AIGC.

I have read the cross-compilation docs, along with Nixpkgs official docs on dependency attributes and mkShell source code. I believe there may be a misunderstanding here, so please allow me to clarify.

1. packages goes to nativeBuildInputs, not buildInputs

This claim doesn't match the mkShell implementation.

    buildInputs = mergeInputs "buildInputs";
    nativeBuildInputs = packages ++ (mergeInputs "nativeBuildInputs");
    propagatedBuildInputs = mergeInputs "propagatedBuildInputs";
    propagatedNativeBuildInputs = mergeInputs "propagatedNativeBuildInputs";


    shellHook = lib.concatStringsSep "\n" (
      lib.catAttrs "shellHook" (lib.reverseList inputsFrom ++ [ attrs ])
    );

packages is merged into nativeBuildInputs. The minimal repro is already using the correct attribute. You can also verify: even if both Rust toolchain and cross GCC are placed directly in nativeBuildInputs, $CC is still set to the cross-compiler.

2. My scenario is not covered by the cross-compilation docs

The cross-compilation docs describe compiling Rust programs for a foreign target (Rust → aarch64). My scenario is different — a hybrid development shell:

• Rust toolchain compiles a native system emulator (x86_64 → x86_64)
• Cross GCC compiles test programs that run inside the emulator (x86_64 → riscv32)

This is a real workflow in embedded/simulator development, but it doesn't fit the standard cross-compilation pattern where everything targets the same foreign platform. I understand the current depsHostHostPropagated design serves the standard cross-compilation case well. I'm just wondering if there's a recommended approach for this hybrid scenario.

3. On AIGC and the analysis

The AIGC is trying to make it "fixed" under the incorrect using pattern, and break the correct using pattern.

I share the concern about not breaking correct patterns — that's precisely why I filed this issue rather than submitting a BUG report or even a PR. However, the core finding (that depsHostHostPropagated in mk-aggregated.nix propagates native gcc via propagated-host-host-deps, which triggers a findInputs deduplication conflict when native and cross compilers coexist in the same shell) was verified against setup.sh and make-derivation.nix source code. This is a factual observation about Nixpkgs' dependency resolution mechanics, not an AIGC hallucination.

---

That said, I want to be honest about why AIGC ended up in this reply. Nix's cross-compilation dependency system involves a non-trivial offset model (-1/0/1), splicing mechanics (__spliced.buildHost), setup.sh's findInputs deduplication, and propagated-*-deps propagation chains — none of which are documented in a way that a newcomer can realistically follow end-to-end. The official docs explain what each attribute does in isolation, but not how they interact when things go wrong.

For most Nix users, especially those who aren't Nixpkgs maintainers like me, AIGC is often the only accessible entry point to even begin investigating these issues. It's not ideal — I'd much prefer comprehensive documentation that makes AIGC unnecessary — but it's the practical reality for the majority of the Nix community today.

I understand the frustration with low-quality AIGC submissions. But dismissing findings purely on the basis of AIGC involvement — when they're source-verified — risks throwing out legitimate issues. I'd appreciate it if we could evaluate the technical merits as they are.

---

Finally, I want to sincerely thank you for taking the time to respond. Maintaining an open-source project like rust-overlay — especially one that sits at the intersection of Rust and Nix's cross-compilation machinery — is no small effort. Your pointer to the cross-compilation docs, even if it didn't fully address my scenario, did help me better understand the intended usage pattern. I appreciate your work, and I'm grateful for the care you put into maintaining this project.

[oxalica]

Thanks for the follow up. I did not know packages points to nativeBuildInputs now (or I just misremembered). But I still think it's a package splicing issue, since you don't use callPackages as in examples. Could you try using callPackages or explicit using buildPackages.rust-bin.[..] and see if either fixes?

If not, I'll check it in details later when I get time.

[PeterWang-dev]

Thanks for the follow up. I did not know packages points to nativeBuildInputs now (or I just misremembered). But I still think it's a package splicing issue, since you don't use callPackages as in examples. Could you try using callPackages or explicit using buildPackages.rust-bin.[..] and see if either fixes?

Thanks for the suggestion! I tried both approaches — here are the results. (I don't know if I get your points.)

Test 1: buildPackages.rust-bin

let
  pkgs = import (fetchTarball "https://nixos.org/channels/nixos-25.11/nixexprs.tar.xz") {
    overlays = [ (import (fetchTarball "...rust-overlay...")) ];
  };
  pkgsCross = pkgs.pkgsCross.riscv32;
in
pkgs.mkShell {
  packages = [
    pkgsCross.buildPackages.rust-bin.stable.latest.default
    pkgsCross.buildPackages.gcc
  ];
}

Test 2: pkgsCross.callPackage (as in the cross-compilation docs)

pkgsCross.callPackage (
  { mkShell, rust-bin, gcc }:
  mkShell {
    nativeBuildInputs = [
      rust-bin.stable.latest.default
      gcc
    ];
  }
) { }

**Both fail with the same error:**

error:
       … while calling the 'derivationStrict' builtin
         at «nix-internal»/derivation-internal.nix:37:12:
           36|
           37|   strict = derivationStrict drvAttrs;
             |            ^
           38|

       … while evaluating derivation 'nix-shell-riscv32-unknown-linux-gnu'
         whose name attribute is located at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/stdenv/generic/make-derivation.nix:541:13

       … while evaluating attribute 'nativeBuildInputs' of derivation 'nix-shell-riscv32-unknown-linux-gnu'
         at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/stdenv/generic/make-derivation.nix:590:13:
          589|             depsBuildBuild = elemAt (elemAt dependencies 0) 0;
          590|             nativeBuildInputs = elemAt (elemAt dependencies 0) 1;
             |             ^
          591|             depsBuildTarget = elemAt (elemAt dependencies 0) 2;

       … while calling the 'getAttr' builtin
         at «nix-internal»/derivation-internal.nix:50:17:
           49|     value = commonAttrs // {
           50|       outPath = builtins.getAttr outputName strict;
             |                 ^
           51|       drvPath = strict.drvPath;

       … while calling the 'derivationStrict' builtin
         at «nix-internal»/derivation-internal.nix:37:12:
           36|
           37|   strict = derivationStrict drvAttrs;
             |            ^
           38|

       … while evaluating derivation 'rust-default-1.95.0'
         whose name attribute is located at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/stdenv/generic/make-derivation.nix:541:13

       … while evaluating attribute 'paths' of derivation 'rust-default-1.95.0'
         at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/build-support/trivial-builders/default.nix:617:11:
          616|           inherit preferLocalBuild allowSubstitutes;
          617|           paths = mapPaths (path: "${path}${stripPrefix}") paths;
             |           ^
          618|           passAsFile = [ "paths" ];

       … from call site
         at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/build-support/trivial-builders/default.nix:617:19:
          616|           inherit preferLocalBuild allowSubstitutes;
          617|           paths = mapPaths (path: "${path}${stripPrefix}") paths;
             |                   ^
          618|           passAsFile = [ "paths" ];

       … while calling 'mapPaths'
         at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/build-support/trivial-builders/default.nix:597:12:
          596|       mapPaths =
          597|         f: paths:
             |            ^
          598|         map (

       … while calling the 'map' builtin
         at /nix/store/77jkbl1irvmawq4sg3338cqfz4h71zck-source/pkgs/build-support/trivial-builders/default.nix:598:9:
          597|         f: paths:
          598|         map (
             |         ^
          599|           path:

       … from call site
         at /nix/store/y3ms9nc6dxcssfvni5m46zb2kv8d4r20-source/lib/rust-bin.nix:410:36:
          409|               availableComponents = componentSet.${rustHostPlatform};
          410|               selectedComponents = resolveComponents {
             |                                    ^
          411|                 name = "rust-${name}-${manifest.version}";

       … while calling 'resolveComponents'
         at /nix/store/y3ms9nc6dxcssfvni5m46zb2kv8d4r20-source/lib/rust-bin.nix:210:5:
          209|   resolveComponents =
          210|     {
             |     ^
          211|       name,

       … while calling the 'throw' builtin
         at /nix/store/y3ms9nc6dxcssfvni5m46zb2kv8d4r20-source/lib/rust-bin.nix:309:7:
          308|     else
          309|       throw ''
             |       ^
          310|         Component resolution failed for ${name}

       error: Component resolution failed for rust-default-1.95.0
       Unknown target `riscv32gc-unknown-linux-gnu`, typo or not supported by this version?
       note: profile components: rustc cargo rust-std rust-mingw rust-docs rustfmt-preview clippy-preview
       note: selected targets: x86_64-unknown-linux-gnu riscv32gc-unknown-linux-gnu
       note: components available for x86_64-unknown-linux-gnu: cargo clippy clippy-preview llvm-bitcode-linker llvm-bitcode-linker-preview llvm-tools llvm-tools-preview reproducible-artifacts rust rust-analysis rust-analyzer rust-analyzer-preview rust-docs rust-src rust-std rustc rustc-dev rustc-docs rustfmt rustfmt-preview
       note: check here to see all targets and which components are available on each targets:
             https://rust-lang.github.io/rustup-components-history

This is because once rust-bin sees a cross context (host=riscv32), it tries to download the Rust stdlib for the host target, but Rust doesn't support riscv32gc-unknown-linux-gnu as a tier target.

The standard cross-compilation pattern (the whole shell targets the same foreign platform, e.g., Rust→aarch64 + GCC→aarch64) works perfectly. But it fundamentally doesn't fit the hybrid case where:

• Rust compiles native code (x86_64 → x86_64)
• GCC compiles cross code (x86_64 → riscv32)

The rustToolchain must stay in the native context (no cross splicing). I guess its internal depsHostHostPropagated = [ stdenv.cc ] still propagates native gcc through propagated-host-host-deps, which collides with the shell's dependency resolution at the setup.sh level when a cross compiler is also present.

Honestly, not only the scenario but also the problem appearances here, both are so weird to me.