llvmPackages.clang: Drop CLANG_DEFAULT_CXX_STDLIB

[pwaller]

This is better handled in the cc-wrapper, and makes it possible to avoid
rebuilding clang in some scenarios.

It also appears to be unnecessary since the cc-wrapper already passes
-stdlib=libc++ where needed.

See:

nixpkgs/pkgs/build-support/cc-wrapper/default.nix

Line 603 in 8885a1e

echo "-stdlib=libc++" >> $out/nix-support/libcxx-ldflags

Signed-off-by: Peter Waller [email protected]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[alyssais]

Ack

[paparodeo]

This is better handled in the cc-wrapper, and makes it possible to avoid rebuilding clang in some scenarios.

it is not obvious to me how it helps rebuilding clang. what scenarios does this cause additional rebuilds? I'd think that dropping the cc-wrapper duplicate would be preferable over dropping properly setting the default at compile time.

[pwaller]

it is not obvious to me how it helps rebuilding clang. what scenarios does this cause additional rebuilds? I'd think that dropping the cc-wrapper duplicate would be preferable over dropping properly setting the default at compile time.

The code removed here gets rid of the only place I can see where the clang derivation varies by targetPlatform.

Clang is a cross compiler by default. So in the best case you only need to build it once and then you can use it for various things by passing different parameters to it. What I want is to use the clang provided by the existing public build, so I don't need to rebuild it, but then use crossSystem to target something else.

This can be arranged with import <nixpkgs> { crossSystem = ...; config.replaceCrossStdenv = { buildPackages, baseStdenv }: somethingInvolving buildPackages.llvmPackages.clang-unwrapped; } to substitute in the compiler from buildPackages, but because the build varies according to the targetPlatform, this requires a rebuild of clang for each one, even though they are functionally identical. This isn't necessary - the wrapper is incredibly cheap to rebuild compared with rebuilding the compiler, it is better if the flag lives there.

[paparodeo]

it is not obvious to me how it helps rebuilding clang. what scenarios does this cause additional rebuilds? I'd think that dropping the cc-wrapper duplicate would be preferable over dropping properly setting the default at compile time.

The code removed here gets rid of the only place I can see where the clang derivation varies by targetPlatform.

aren't the build inputs different tho?
[edit] tried a build without the compile flag and observed clang not getting rebuilt.

[RossComputerGuy]

To note, the flag was misinterpreted in its use. Source