How to create a working LLVM-based stdEnv for C++ development?

[BENDI]

@hoyhoy

I have nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11"; in my flake.nix and system.stateVersion = "25.11"; in my /etc/configuration.nix. Is 21.1.7 the latest 25.11 LLVM release? Or is that unstable?

FYI system.stateVersion doesn’t have anything to do with the version of nixpkgs you are actually pulling docs. At the moment (if you just recently installed NixOS) that value might even be “correct” in your case, but your nixpkgs input will get updated over time, while your system.stateVersion should stay the same.

What actually determines your nixpkgs version are your system channels or the inputs to your system flake, depending on what you are using.

When you run nix eval nixpkgs#<something> the nixpkgs instance referenced is determined by your configured flakerefs (nix registry list). On my flake-enabled system the nixpkgs flakeref is set to the nixpkgs instance which was used to build the system. I don’t know what happens when you are not using flakes, but if the ref is not explicitly set it falls back to nixpkgs-unstable (which AFAIK is not recommended for use as a system nixpkgs instance).

I realize this might not be relevant to the issues you were/are facing, but it might prevent a bunch of headaches in the future.

[TLATER]

@BENDI

On my flake-enabled system the nixpkgs flakeref is set to the nixpkgs instance which was used to build the system. I don’t know what happens when you are not using flakes, but if the ref is not explicitly set it falls back to nixpkgs-unstable (which AFAIK is not recommended for use as a system nixpkgs instance).

To clean up some small details, this is only true if nixpkgs.flake.setFlakeRegistry is set, rather than “flake enabled”; just setting the nix config to allow using flakes doesn’t change the registry entry.

If you are “not using flakes”, there is no flake registry, because you’re not using flakes. If by that you mean a NixOS installation that isn’t sourced from a nixpkgs retrieved through flake inputs, by default nix will use the global registry.

The nixpkgs entry in the global registry does default to the nixpkgs-unstable branch, which indeed should not be used for building NixOS, but if you’re using the global registry that’s not what you’re doing so it’s all fine.

[BENDI]

Perhaps I mis-spoke when I said “flake-enabled”, but meant “built from a flake”.

TIL how nixpkgs.flake.setFlakeRegistry is set. Thanks!

What do you mean by “there is no registry”? Does the global registry not count or were you only concerned about the local registry?

I mentioned that, because they ran nix eval nixpkgs# and thus were potentially using the global registry.

I also noticed that you put “not using flakes” in quotes. Did you do this, because you find this description to be imprecise (if so how should such a setup be described?) or just to make clear that you are quoting someone?

[TLATER]

@BENDI

just to make clear that you are quoting someone?

I’m quoting you:

@BENDI

I don’t know what happens when you are not using flakes

@BENDI

I mentioned that, because they ran nix eval nixpkgs# and thus were potentially using the global registry.

Yes, that’s my point as well. Though your use of the terms is imprecise (I think?), the global registry refers specifically to the json file I linked; that’s what nix downloads to find out what your nixpkgs refers to.

When using nix eval nixpkgs#, you’re using flakes; there is no way to use the flake URI syntax without using flakes. I take issue with the term “flake-enabled”, because it’s not a well-defined term; It sounds like all you do is set --experimental-features=flakes, when you (probably?) mean NixOS built with that option set to true.

There is also no such thing as a “local registry”. There are global, system and user registries.

Basically, what you’re saying seems mostly correct, but it uses imprecise language and misses some nuance; I’m not sure if that’s because you don’t fully understand it or if you’re just being imprecise on accident. This might seem like splitting hairs, but I think being precise is important for people who try to learn from your comment, so I’m trying to pad out what you said with some clarifications, I’m not outright disagreeing with you or anything.

[RossComputerGuy]

@randomizedcoder

Part of the challenge is that while there is some great documentation, there are many different versions of packages. These names probably make sense to some people, and I’m sure those more familiar think it’s obvious, but I’ve certainly struggled.

I’m not sure what you mean by “many different versions of packages”. Most of the LLVM package sets are composed of actual packages, wrapped C compilers, and stdenv’s.

@randomizedcoder

Things seem to get most hairy with the order of definition, which are mutually exclusive, and these sorts of combinatorial possibilities.

Wdym by order? A lot of these packages don’t have a strict ordering, unless you’re referring to the stdenv’s and CC wrappers.

@randomizedcoder

What’s the difference? = I can vaguely guess

What order should they be included in?

Which ones can’t be combined without trying to build and it blowing up?

A lot of the CC wrappers & stdenvs can be ignored. The one stdenv most people will need is libcxxStdenv, and the one CC wrapper most people will end up using is clangUseLLVM.

libcxxStdenv is a basic LLVM stdenv, mainly containing clang & libc++.

clangUseLLVM is a full LLVM & clang CC environment, requires using overrideCC stdenv to inject it into a stdenv.

@randomizedcoder

It would be amazing to have:

1. Overview document with the design intention. This doc would explain how and why the packages are categorized and split up the way they are
2. For each package, to have more detailed explanation

Maybe this already exists somewhere more upstream in the clang, although I suspect people who have been dealing with for years “just know”

There’s some documentation in the nixpkgs manual. Feel free to contribute.

Nixpkgs Reference Manual

[hoyhoy]

Thanks for the help @BENDI, @RossComputerGuy, @TLATER…

I had the nixpkg url set in my flake, but nix eval was using the global registry even if I pointed to the flake.lock file. I guess I needed to set nixpkgs.flake.setFlakeRegistry = true; in my flake.nix for that to work though…

I ended up removing the llvmPackages from my configuration.nix and home.nix after @RossComputerGuy recommended setting them in my project directory’s flake.nix.

This was what I was failing to accomplish with nix eval, but now using direnv and the overrideCC that @RossComputerGuy recommended (which did fix my my libcxx issues)…

nix eval .#devShells.x86_64-linux.default.stdenv.cc.outPath --raw
/nix/store/wp328h9diq2ybqyml065qyflwzx14iry-clang-wrapper-21.1.2

nix eval .#devShells.x86_64-linux.default.stdenv.cc.libcxx.outPath --raw
/nix/store/i4si6cf5icjxfnphzrd769nf8jkypiz9-libcxx-21.1.2

nix eval .#devShells.x86_64-linux.default.nativeBuildInputs --apply 'x: map (d: d.name) x'
[ "llvm-binutils-wrapper-21.1.2" "clang-tools-21.1.2" "lldb-21.1.2" "lld-21.1.2" "llvm-21.1.2" "automake-1.18.1" "autoconf-2.72" "conan-2.21.0" "ccache-4.12.1" "cmake-4.1.2" "gperf-3.3" "gnumake-4.4.1" "libtool-2.5.4" "nasm-2.16.03" "gnum4-1.4.20" "perl-5.40.0" "python3-3.13.9" "ruby-3.4.8" "rake-13.2.1" "stdenv-linux" ]

nix eval .#devShells.x86_64-linux.default.nativeBuildInputs --apply 'x: (builtins.head x).bintools_bin.outPath' --raw
/nix/store/7hhzb302q1lmjz5pjryg4xi8s600ah1a-llvm-binutils-21.1.2

nix eval '.#devShells.x86_64-linux.default.nativeBuildInputs' --apply 'x: (builtins.head (builtins.filter (d: builtins.hasAttr "pname" d && d.pname == "llvm-binutils-wrapper") x)).outPath'
/nix/store/sax2n5wrrc4xbsyxdf8i8cd1grh5556k-llvm-binutils-wrapper-21.1.2

llvm-config --bindir
/nix/store/sc3i8b2x6lwrv2pxrv6vmanmb0wf7xcg-llvm-21.1.2/bin

[hoyhoy]

This seems sort of odd.

nix eval '.#devShells.x86_64-linux.default.nativeBuildInputs' --apply 'x: (builtins.head (builtins.filter (d: builtins.hasAttr "pname" d && d.pname == "llvm-binutils-wrapper") x)).outPath' --raw
/nix/store/sax2n5wrrc4xbsyxdf8i8cd1grh5556k-llvm-binutils-wrapper-21.1.2

❯ md5sum $(which addr2line)
094d812bbb6946f4e683f60adda76e08  /nix/store/sax2n5wrrc4xbsyxdf8i8cd1grh5556k-llvm-binutils-wrapper-21.1.2/bin/addr2line

❯ md5sum $(which llvm-symbolizer)
094d812bbb6946f4e683f60adda76e08  /nix/store/7hhzb302q1lmjz5pjryg4xi8s600ah1a-llvm-binutils-21.1.2/bin/llvm-symbolizer

IIRC, I added llvm to my flake.nix to get access to llvm-symbolizer, but it looks like llvm-symbolizer was linked to addr2line in the wrapper. Not exposing llvm-symbolizer to the path breaks my tooling since my binaries are configured in the source code to point to the cmake find_program() version…

[hoyhoy]

The latest … How do I get access to clang’s bash-autocomplete.sh…

Future note… This works:

      shellHook = ''
        llvm_root=${pkgs.llvmPackages.clang-unwrapped}
        echo ''${llvm_root}
        [[ -n "''${llvm_root:-}" && -f "''${llvm_root}/share/clang/bash-autocomplete.sh" ]] && \
          echo "''${llvm_root}/share/clang/bash-autocomplete.sh"
          . "''${llvm_root}/share/clang/bash-autocomplete.sh"
      '';

It’s part of the unwrapped clang, but not deployed to the wrapper…

fd  'bash-autocomplete.sh' /nix/store
/nix/store/jxclrnb73vx9iw56r1cfb5pdcbd14m57-clang-21.1.2/share/clang/bash-autocomplete.sh