| 29 Jan 2026 |
 Randy Eckenrode | The biggest help will be testing. Try building packaged Swift applications as well as ones in a dev shell. It should work. The goal is to make it a good experience for packaging and for local development. | 13:43:13 |
| Randy Eckenrode | If there are packages that need things that have been drops, I want to know, so I can investigate why. | 13:43:37 |
| Randy Eckenrode | For example, swift.swift is gone. Were you just doing that to get an unwrapped compiler? | 13:44:07 |
| Randy Eckenrode | The compiler is now unwrapped. | 13:44:29 |
| Randy Eckenrode | Using xcbuild with Swift dependencies? I want to make that work. | 13:45:21 |
| Randy Eckenrode | Using NIX_SWIFTFLAGS_COMPILE? It’s no longer supported due to Swift being unwrapped. How was that being used? | 13:46:15 |
| Randy Eckenrode | Need to link non-Swift dylibs? Does that still work? | 13:46:35 |
| Randy Eckenrode | If there are easy test cases, they can be put in passthru.tests. I’ve already updated the C++ interop test for both-way interop. | 13:47:30 |
| Randy Eckenrode | We can now use Swift from C++ in addition to C++ from Swift. | 13:48:02 |
| Randy Eckenrode | Other bonus things I hope will work is cross-compilation and using stdlibs for other targets. | 13:48:37 |
| Randy Eckenrode | Static is another one that needs testing. | 13:49:48 |
| 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 |
