| 13 Feb 2026 |
 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 |
| emily | IMO we should just control the default with that rather than with wrapper flags. though on macOS we are not building libc++ anyway | 15:52:41 |
| ris_ | interesting - we might have to do some hackery as I wouldn't expect _LIBCPP_HARDENING_MODE_DEFAULT to be designed to be set from the cli | 17:31:34 |
| emily | no I just mean we should set it in our libc++ build :) | 17:58:50 |
| emily | like how we do PIE by default in our GCC and Clang builds | 17:59:13 |
| emily | overriding for an individual package can be flag driven | 17:59:26 |
| emily | though I think NIX_CFLAGS_COMPILE is probably sufficient interface there | 18:00:02 |
| ris_ | i seeee | 18:02:04 |
| ris_ | yeah i just think it's weird, people will expect that setting hardeningDisable = ["libcxxhardeningfast"]; to actually disable it | 18:02:58 |
| ris_ | * yeah i just think it's weird, people will expect setting hardeningDisable = ["libcxxhardeningfast"]; to actually disable it | 18:47:29 |
| emily | might be good to support hardeningDisable adding flags? but if we control it with the build-time default + cflags maybe it can just be an override in pkgsExtraHardening and not need the hardening* machinery at all | 20:34:31 |
| 15 Feb 2026 |
|  ilsubyeega (backup) joined the room. | 02:36:46 |
| 16 Feb 2026 |
|  zimward changed their display name from zimward to zim. | 13:48:43 |
| zimward changed their display name from zim to zimward. | 13:50:09 |
| 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 |
