Rust build includes strange `rust-default` derivation in output?

Problem

I have the following rust CLI tool default.nix which you can build with:

nix build "github:sdsc-ordes/catplus-converters?dir=tools/nix&ref=80025843a21e570ee86f6077360bffb07ae8f63d#catplus-converters" --print-out-paths

> /nix/store/pj638k9z33d5z125ainqhai16a79dax5-catplus-converters

I use the rust-overlay from oxalica:

# The Rust overlay to include the latest toolchain.
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs = {
        nixpkgs.follows = "nixpkgs";
      };
    };

When I analyze this with nix-tree :

nix-tree /nix/store/pj638k9z33d5z125ainqhai16a79dax5-catplus-converters

I see a huge dependency which is the /nix/store/fij1508sgwggn17ypmkj98ly5fcbrlmp-rust-default-1.88.0-nightly-2025-04-16
of about 1. 75 GiB:

The ldd only reports the following deps:

ldd /nix/store/pj638k9z33d5z125ainqhai16a79dax5-catplus-converters/bin/converter
        linux-vdso.so.1 (0x00007ffe5b57b000)
        libc.so.6 => /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 (0x00007f8858800000)
        /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/ld-linux-x86-64.so.2 => /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007f885919b000)
        libgcc_s.so.1 => /nix/store/ik84lbv5jvjm1xxvdl8mhg52ry3xycvm-gcc-14-20241116-lib/lib/libgcc_s.so.1 (0x00007f885916b000)

Questions

  • Does anybody know why that happens cause these bloat dependencies seem to be build inputs only?? and what I can do to analyze that better, this is a fairly simple Rust app with some dependencies etc.
  • Does the rust-default somehow sneaks in by vendored dependencies?

Have a look here maybe:

rust requires a lot to compile, analyze, debug, etc
There are some tweaks you can do to reduce the size but overall, projects tend to be large

Depencies listed (rust-docs, rust-analyzer, clippy, etc) seem about right and what you would need to get a smooth development experience (formatting, debuggin, quick compile time, etc)

Thanks for the references! I am just puzzled why rust-default even is part of the final derivation eventhough its not ? needed to run the application AFAIS… its just strange because these things seem to me like build dependencies…

rust-default comes from the oxalica/rust-overlay overlay you’re using or am I missing smth?

From repo examples, see the profile arg is set to default: rust-overlay/examples/hello-world/shell.nix at ec22cd63500f4832d1f3432d2425e0b31b0361b1 · oxalica/rust-overlay · GitHub
Which then uses: rust-overlay/manifests/profiles.nix at ec22cd63500f4832d1f3432d2425e0b31b0361b1 · oxalica/rust-overlay · GitHub (or from another line in the same file)

So there is complete, default and minimal => would assume using e.g complete, you’ll get rust-complete instead of your current rust-default

rust is a compiled language so these are needed in order to run any rust projects. One can not call a .rs file, it needs to be compiled so then one can call the binary output.
Or maybe I’m misunderstanding you?

There is a missunderstanding here: Its all about the single $out/converter in the final derivation, which is a ELF executable and for which some how Nix thinks it needs /nix/store/...rust-default-... because thats what Nix found as runtime dependencies when have done the anaylysis after the build etc. (I suspect it does not do a simple strings analysis of the binary, right?).

The strange thing is using nightly-2024-06-17 instead of nightly will not have this behavior and the link to rust-default- store path is gone, so when using this

[toolchain]
channel = "nightly-2024-06-17"
components = [ "rustfmt", "rust-analyzer", "miri", "rust-docs", "clippy", "rust-src"]
profile = "default"

I am seeing patching beeing done for the toolchain

cargo> automatically fixing dependencies for ELF files
cargo> {'add_existing': True,
cargo>  'append_rpaths': [],
cargo>  'extra_args': [],
cargo>  'ignore_missing': [],
cargo>  'keep_libc': False,
cargo>  'libs': [PosixPath('/nix/store/hfkclq54gppdb9fshnkwfdph1safyvli-gnutar-1.35/lib'),
cargo>           PosixPath('/nix/store/yip39c32hz27ix425p14q6pw7w8i598g-auto-patchelf-hook/lib'),
cargo>           PosixPath('/nix/store/214vrsiv784x6marqh27ips2r4p6pq34-auto-patchelf-0-unstable-2024-08-14/lib'),
...

Is that the reason for it? Maybe somebody from the Rust toolchain maintenance team in nixpkgs might answer this:

@emily, @shamrocklee: Do you might have a clue?

1 Like

Ok, apparently the components = section now influences runtime-dependencies on newer toolchains (?).
So the solution is to make a toolchain.toml file for Nix building not use components etc.

I’ve had a similar issue months ago, which was caused by store paths being leaked into the ELF and thus added as dependencies. At the time I’ve solved the issue with RUSTFLAGS="--remap-path-prefix" which then remapped the store path to something else.

1 Like

Did you use RUSTFLAGS = "--remap-path-prefix=$NIX_BUILD_TOP=/"; I only see this used in
buildRustCrate in nixpkgs?
Thanks for the hint, so far adding this flag to the build did not really help.

The solution is the following: