cc-wrapper: add glibcxxassertions hardening flag

[risicle]

This adds another flag included in the 2025 openssf hardening guide: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html#precondition-checks-for-c-standard-library-calls

As ever, as a new hardening flag I have disabled it by default except in pkgsExtraHardening. Because of the possibility of slowdowns, this is one of the flags I probably won't advocate moving to default-enabled any time soon.

This hardening flag is a little bit odd because it only has an effect when compiling against glibc's libstdc++, but note how I haven't included any mechanism to "unsupport" it on platforms that use libc++. This is because we don't currently have any nice mechanism to detect what c++ standard library a platform is using - and whether we're using clang or gcc is a poor approximation of this. Instead this PR will happily add the -D_GLIBCXX_ASSERTIONS definition on all platforms, whether using libstdc++ or not, with the idea that other c++ standard libraries will just ignore it.

Clang's libc++ does have a similar feature that I'm planning on introducing in a separate PR. Why not put both flags under a common generic hardening flag name? Firstly I'm not convinced that the assertions of each library will have similar enough package-breaking characteristics, and secondly libc++'s hardening feature has multiple levels that I think are worth exposing separately. Once we get into multiple levels of strictness, ensuring sensible parity between the exposed levels between the two implementations feels like it would be a fool's errand.

I built quite a lot of c++ packages on aarch64-linux with this default-enabled and only found arrow-cpp's build to be affected by it.

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/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (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.

[reckenrode]

This is because we don't currently have any nice mechanism to detect what c++ standard library a platform is using - and whether we're using clang or gcc is a poor approximation of this.

Can’t we check for libc++ by checking for libcxx being non-null in the wrapper?

Considering that it’s possible to use libc++ on Linux (which uses libstdc++ by default) and libstdc++ on Darwin (which uses libc++), the place to check would be in the wrapper (assuming it is desired to check and toggle these assertions on our off based on the target C++ stdlib).

[risicle]

So.. we probably could, but that would involve putting the logic into cc-wrapper's default.nix, and I've been trying to move logic out of cc-wrapper into the compiler derivation passthrus. And that's what I'd consider a "nice" way of doing it - having the c++ library derivation self-report unsupported flags. libstdc++ doesn't even have an identifiable package to annotate this onto.

[reckenrode]

libstdc++ doesn't even have an identifiable to annotate this onto.

So maybe putting it there if/when GCC gets split into separate packages?

[philiptaron]

What's new in these changes Robert @risicle?

Note that GCC in multiple packages landed

• gccNGPackages: init #414299

[risicle]

It looks like gccNGPackages hasn't yet implemented hardeningUnsupportedFlags or hardeningUnsupportedFlagsByTargetPlatform - I should probably tell someone. It looks like a step in the right direction, but I don't think this will be able to perform c++ lib detection until we decide upon a standard stdenv attr for it a la stdenv.cc.

Apart from a straight rebase, this PR hasn't changed since posting.

[philiptaron]

Someone would be John @Ericson2314 or Tristan @RossComputerGuy for gccNGPackages, I believe.

[philiptaron]

I'm fine with trusting @risicle on this. Randy do you object enough to close the PR until another way is found?