Unable to access clang tools in clangStdenv

[SharzyL]

Describe the bug

When working with clangStdenv (note that stdenv for darwin uses clang), the binaries of clang tools are provided in the path of clang-unwrapped. However, these binaries are unwrapped and cannot properly resolve system header paths.

If we want to use the wrapped one, they are provided in the package clang-tools. But even if we add clang-tools to nativeBuildInputs, we still get the unwrapped version, since the path of clang-tools is placed after clang-unwrapped in PATH. Is there a clean way to access unwrapped clang tools?

Steps To Reproduce

Enter the following nix shell:

with import <nixpkgs> {};
(mkShell.override {stdenv = clangStdenv;}) {
  nativeBuildInpus = [ clang-tools ];
  shellHook = ''
    which clang-tidy
  '';
}

It shows

/nix/store/5jinmjv3rhgw97qiq62lvhppy4lsm680-clang-11.1.0/bin/clang-tidy

which means clang-tidy is the unwrapped version.

Expected behavior

There should be a clean way to access the wrapped clang tools.

Additional context

A possible solution is to remove the clang-tool binaries from unwrapped clang. Or any better solution?

Notify maintainers

@Ericson2314 @sternenseemann @dtzWill @primeos

Metadata

• system: "x86_64-linux"
• host os: Linux 6.1.6, NixOS, 23.05 (Stoat), 23.05pre-git
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.12.0
• channels(root): ""
• channels(sharzy): ""
• nixpkgs: /nix/store/ld350gbq2w5654yw4q95kxhxp4569zi6-source

[NickCao]

The correct fix might be moving clang-tools out of clangStenv.

[SharzyL]

clang-tools is a batch of wrappers of binaries in clang-unwrapped. Hence the steps might be:

1. Separate the tools in clang-unwrapped to an extra output
2. Modify clang-tools to use the new output
3. Fix regressions

[Avimitin]

Is there any update on this issue? It's quite frustrating to have to manually add clang-tools to the PATH just to have a working clangd binary.

[zeratax]

I am also struggling with this and have no clue how to get clang-tidy to work

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/take-clang-tools-over-executables-in-llvmpackages-stdenv/39831/2

[gracicot]

I'm also affected by this issue. Unwrapped clang tooling should only be provided when we specifically use clang-tools-unwrapped or something like that.

[gracicot]

Another point: Right now, packages using C++20 modules do not build by default, and simply errors out. This is because clang-scan-deps shipped in the clang package is unwrapped, and cannot find standard library headers. The only one usable is from clang-tools, which the executables are inaccessible from PATH since clang executables take over. For nix package using C++20 modules to be usable, clang-scan-deps needs to be wrapped.

I think it would be reasonable to make them either wrapped by default in clang, or let clang-tools by prioritized over clang's packages or make clang not ship any tools by default. Either of those three solution would make C++20 modules and LSP to finally work out of the box.

Since a working wrapped clang-tools are becoming required to build some packages, I would recommend making those from the stdenv wrapped by default, and allow users to override it with clang-tools-unwrapped if needed.

[yukula]

@gracicot Thank you so much. It has been driving me crazy for a couple of days. CXX_SCAN_FOR_MODULES is 'ON' by default in cmake 3.28 (. So it breaks compilation even if you do not use modules in the project.

Example(unstable channel):

cmake 3.29 gets populated with current nixpkgs.

with import <nixpkgs> {};
pkgs.mkShell.override { stdenv = pkgs.llvmPackages_18.stdenv; } {
    packages = with pkgs; [ 
      cmake
    ];
}

#include <iostream>
int main()
{
  std::cout << "hello world\n";
  return 0;
}

> cmake ../ -GNinja
-- The CXX compiler identification is Clang 18.1.4
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /nix/store/2p36b6gd1sy0s3z952rlylwdm3pari56-clang-wrapper-18.1.4/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.3s)
-- Generating done (0.0s)

> ninja 
[1/4] Scanning /home/yukula/Proj/cppcamp/main.cxx for CXX dependencies
FAILED: CMakeFiles/hello.dir/main.cxx.o.ddi
"/nix/store/gyl04ilm9lvzy092a2sh27023d5r1b9r-clang-18.1.4/bin/clang-scan-deps" -format=p1689 -- /nix/store/2p36b6gd1sy0s3z952rlylwdm3pari56-clang-wrapper-18.1.4/bin/clang++   -std=gnu++20 -x c++ /home/yukula/Proj/cppcamp/main.cxx -c -o CMakeFiles/hello.dir/main.cxx.o -MT CMakeFiles/hello.dir/main.cxx.o.ddi -MD -MF CMakeFiles/hello.dir/main.cxx.o.ddi.d > CMakeFiles/hello.dir/main.cxx.o.ddi.tmp && mv CMakeFiles/hello.dir/main.cxx.o.ddi.tmp CMakeFiles/hello.dir/main.cxx.o.ddi

Now if I disable CXX_SCAN_FOR_MODULES:

> cmake ../ -GNinja -DCMAKE_CXX_SCAN_FOR_MODULES=OFF
-- The CXX compiler identification is Clang 18.1.4
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /nix/store/2p36b6gd1sy0s3z952rlylwdm3pari56-clang-wrapper-18.1.4/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.3s)
-- Generating done (0.0s)

> ninja
[2/2] Linking CXX executable hello

Workaround

with import <nixpkgs> {};
pkgs.mkShell.override { stdenv = pkgs.llvmPackages_18.stdenv; } {
    packages = with pkgs; [ 
      clang-tools_18 #https://github.com/NixOS/nixpkgs/issues/214945
      # ...
    ];
}

[gracicot]

@yukula actually, I solved this by adding clang-tools_18 to nativeBuildInputs and it has worked pretty well for me.