Hi @rrbutani. I'm trying to set up the llvmPackages_15 toolchain in a development environment for rules_ll to get a reproducible host compiler.

With a shell.nix like

pkgs.mkShell {
  buildInputs = [
    pkgs.llvmPackages_15.bintools
    pkgs.llvmPackages_15.clang
    pkgs.llvmPackages_15.compiler-rt
    pkgs.llvmPackages_15.libcxx
    pkgs.llvmPackages_15.libcxxabi
    pkgs.llvmPackages_15.libunwind
    pkgs.llvmPackages_15.lld
  ];
}

I'm having some trouble getting this toolchain to work as I want to though 😅 Either this comes from misconfiguration on my end or some issues in the nix package. I'm also finding it rather hard to find documentation on this.

1. I can't seem to be able to encapsulate the toolchain from its gcc depencencies. First off I think its less than ideal that I'd have to run clang like

clang -stdlib=libc++ -fuse-ld=lld -rtlib=compiler-rt main.cpp

and even then I'm still seeing artifacts of -L/nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/lib64/gcc/x86_64-unknown-linux-gnu/11.3.0 in the linker path. I think invoking clang instead of clang++ for c++ is discouraged anyways, but clang++ does not work with these simpler options.

2. For some reason clang++ seems to ignore -stdlib=libc++ and the host's /usr/include/c++/v1 leaks into clang++ invocations:

clang++ -stdlib=libc++ main.cpp

In file included from main.cpp:1:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/iostream:39:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/ostream:38:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/ios:42:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/bits/ios_base.h:41:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/bits/locale_classes.h:40:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/string:55:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/bits/basic_string.h:6608:
In file included from /nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/ext/string_conversions.h:41:
/nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/cstdlib:177:3: error: declaration conflicts with target of using declaration already in scope
  div(long __i, long __j) { return ldiv(__i, __j); }
  ^
/usr/include/c++/v1/stdlib.h:150:41: note: target of using declaration
inline _LIBCPP_INLINE_VISIBILITY ldiv_t div(long __x, long __y) _NOEXCEPT {
                                        ^
/nix/store/z1yw9cw97bcdfmxz5wk7j1bycw42r1mw-gcc-11.3.0/include/c++/11.3.0/cstdlib:145:11: note: using declaration
  using ::div;
          ^

The Clang docs encourage a pattern like this for encapsulation, but I think it should be possible to default to this behavior on the nix side:

clang++ -nostdinc++ -nostdlib++             \
          -isystem <install>/include/c++/v1 \
          -L <install>/lib                  \
          -Wl,-rpath,<install>/lib          \
          -lc++                             \
          main.cpp

3. The default linker is ld. This seems be the case for the llvmPackages_15.stdenv as well. Would it be possible to change this default to lld on the nix package side? Otherwise one would have to use -fuse-ld=lld or $LD=ld.lld overrides which I find rather unintuitive on a pure Clang/LLVM toolchain.

4. A similar issue seems to be true for the bintools. This is how the Make variables currently look like:

AR=ar
NM=nm
STRIP=strip
OBJCOPY=objcopy
OBJDUMP=objdump
RANLIB=ranlib
READELF=readelf

It would be nice if there was an obvious way to make these use their llvm counterparts instead without having to set this manually. I initially thought they were symlinks to the llvm variants already but it turned out that ar --help and llvm-ar --help do in fact point to different tools.

I'm kinda new to nix so I may be overlooking a few things here. It may also be relevant that I'm using Gentoo with the experimental clang profile, which is one of the very few (the only?) linux distros using clang/glibc system toolchain.