| 29 Jan 2026 |
 Randy Eckenrode | I would also like to support Windows, WASM, and Android; but those are bonuses. | 13:54:47 |
 Ihar Hrachyshka | link to a bug report and/or details of what's going on at least? | 15:29:29 |
 eveeifyeve | I don't think they reported the issue directly, but I know about it hearing from ericson. | 15:30:18 |
| Ihar Hrachyshka | ericson? a man? a company? :) | 15:30:42 |
| eveeifyeve | John Ericson. | 15:31:08 |
| Ihar Hrachyshka | I guess I will proceed with bisect but...
$ git bisect visualize --no-merges --oneline
d4fd918e2cc2 libarchive: fix cygwin build
f4cd05d2e7c9 haskellPackages: mark builds failing on hydra as broken
4922225f956f haskellPackages.rhine-bayes: downgrade to match rhine
51c78494b9ff openldap: use --replace-fail instead of --replace
b770f35b4de1 openldap: fix build with structuredAttrs
79429223426a moltenvk: 1.4.0 -> 1.4.1
70f40e0a3b82 python313Packages.aiodns: 3.5.0 -> 3.6.1
50776d0e56eb apple-sdk: drop `FamilyDisplayName`
176c6512ba96 darwin.libcxx: 19.1.2+apple-sdk-15.5 -> 20.1.0+apple-sdk-26.0
Randy Eckenrode fyi
| 17:14:36 |
| Ihar Hrachyshka | anyone up to try the revert of 176c6512ba96 while I'm proceeding with the current bisect? | 17:18:01 |
|  shorden joined the room. | 17:26:56 |
| Randy Eckenrode | The idea that updating the libc++ headers would break the Swift compiler hurts my head. | 17:54:05 |
| Randy Eckenrode | Or maybe it’s that plus the hardening flags interacting badly for our 5.10.1 build. | 17:54:35 |
| Ihar Hrachyshka | I think folks on github refuted the hardening theory | 17:54:58 |
| Randy Eckenrode | Though that wouldn’t explain Linux. | 17:55:23 |
| Ihar Hrachyshka | is linux crashing the same way | 17:55:49 |
| Ihar Hrachyshka | thought it's darwin only (with swift-frontend burning) | 17:56:22 |
 samasaur | Linux was already broken in a different way; unsure if this new issue affects it too | 18:12:56 |
| Ihar Hrachyshka | if it's darwin.libcxx it just can't | 18:16:23 |
| eveeifyeve | I am just building your update-branch. WIth nix build .#swift | 18:16:28 |
| samasaur | In reply to @ihar.hrachyshka:matrix.org
if it's darwin.libcxx it just can't yea. from a "solving this" standpoint I hope it is libcxx. from an "our shared sanity" standpoint I hope it isn't | 18:22:59 |
| Ihar Hrachyshka | what would be the approach forward if we confirm the bump for libcxx is the problem? is it realistic to revert it while this is being fixed? | 18:23:34 |
| samasaur | vendor the old version inside the swift directory? | 18:23:50 |
| Ihar Hrachyshka | ah right. the power of Nix :p | 18:24:20 |
| samasaur | actually that wouldn't work I think... | 18:26:18 |
| samasaur | bc swift doesn't reference darwin.libcxx directly | 18:26:27 |
| samasaur | it builds the LLVM one | 18:26:39 |
| samasaur | so if libcxx broke something it's due to transitive behavior I think | 18:26:50 |
| Ihar Hrachyshka | "just" build a second stdenv tree for swift? | 18:26:52 |
| samasaur | dear god I hope not | 18:27:37 |
| samasaur | maybe try and track down which specific package is causing the transitive error? | 18:27:57 |
| samasaur | a dependency could have actually different behavior due to availability checking, if I understand correctly | 18:28:38 |
| samasaur | and knowing what the actual difference is might help | 18:28:54 |
