| 13 Feb 2026 |
 emily | doesn't sound like it should be too bad | 03:27:33 |
| emily | specifically marked as suitable for production at least | 03:27:56 |
| emily | fwiw the main user of libc++ in Nixpkgs is macOS and _LIBCPP_HARDENING_MODE_DEFAULT is already 2 (fast) on that platform | 03:29:42 |
| emily | so libcxxhardeningfast is just a nop | 03:30:04 |
|  hoplopf joined the room. | 10:25:27 |
 ris_ | hmmmmmmmmmmmm | 21:51:10 |
| ris_ | well.. open to opinions. i should at least update the documentation to correspond to reality | 21:51:54 |
| emily | I like hardening, but I'm also okay with us matching the platform default here | 22:20:08 |
| emily | not sure if nobody noticing means that the impact is minimal or that nobody is monitoring Nixpkgs package perf 🫣 | 22:20:30 |
| ris_ | i fear the latter | 22:33:54 |
 Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
not sure if nobody noticing means that the impact is minimal or that nobody is monitoring Nixpkgs package perf 🫣 I sure am monitoring nix perf :) glibcxx assertions absolutely tank inlining in the parser | 23:54:31 |
| emily | I don't think that cleanly maps to libc++ hardening though | 23:55:00 |
| emily | (and probably ~nobody is using Nix with libc++ on Linux) | 23:55:14 |
| Sergei Zimmerman (xokdvium) | I think glibcxx assertions are roughly second level libc++ hardening. At least that’s what meson enables with n_debug | 23:56:14 |
| Sergei Zimmerman (xokdvium) | In my experience the overhead is enough to necessitate disabling hardening for some translation units that are just too hot and aren’t security sensitive | 23:57:38 |
| emily | second level = fast (numeric value 2) or extensive? | 23:58:24 |
| emily | because macOS upstream default is fast so we certainly wouldn't go below that OOTB | 23:58:31 |
| emily | would be interesting to see if 25.05 → 25.11 regresses macOS Nix perf anyway | 23:59:07 |
| emily | (but controlling for version might be hard?) | 23:59:12 |
| Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
because macOS upstream default is fast so we certainly wouldn't go below that OOTB As in the llvm toolchain enables that by default? | 23:59:13 |
| 14 Feb 2026 |
| emily | yes:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config_site
43:#define _LIBCPP_HARDENING_MODE_DEFAULT 2
| 00:00:26 |
| emily | (2 is fast) | 00:00:29 |
| Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
would be interesting to see if 25.05 → 25.11 regresses macOS Nix perf anyway Hm, I guess the only way to tell is to benchmarking :) I could see about how that would affect nix itself. Undefing the flag should be easy enough | 00:05:09 |
| ris_ | i'm going to prepare a PR to switch back to fast | 11:04:39 |
| ris_ | this does make me wonder how libcxxhardening* should interact with _LIBCPP_HARDENING_MODE_DEFAULT though | 11:30:03 |
| ris_ | https://github.com/NixOS/nixpkgs/pull/490358 | 12:07:04 |
| 4 Aug 2022 |
|  Winter (she/her) joined the room. | 03:27:09 |
|  [0x4A6F] joined the room. | 22:08:01 |
| 6 Aug 2022 |
| Winter (she/her) | Does anyone know where the fact that the Darwin stdenv builds CMake twice comes from? As far as I can tell, it's from stage 0, and then just gets used in the other stages from there. Am I missing something here, is it something with the overrides? It looks like it might be, but then the fact that those are only allowed in the final stage (per booter.nix) (when that doesn't seem true, since then they wouldn't be defined...?) comes up.
(Isn't this the same pattern (defining in one stage and referencing in the others) that makes Glibc only build a limited number of times in the Linux stdenv?) | 08:00:17 |
 trofi | You think cmake should be rebuild less? Or more?
glibc's is probably a bit different as it's a part of stdenv.cc.libc and mainly used by that I would guess. Also, if depends if the package is used or not by other packages in the derivation would affect rebuild count as well.
| 14:59:09 |
