| 10 Apr 2026 |
 Randy Eckenrode | I did just confirm though that SwiftPM 5.10.1 supports putting packages in editable mode. That’s how I’m vendoring dependencies. I want to land the breaking stuff for the release, then I can work on the Swift 6.x update. | 04:59:11 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/508474 definitely has no rebuilds on either Darwin or Linux. | 05:17:45 |
|  jyap joined the room. | 19:46:58 |
| jyap | so the latest macos tahoe 26.4 seems really hostile now to built CLI apps. they don't even run for testing.
is there a solution for this where the command is just killed by the OS?
e.g.
> _________________ ERROR collecting ffmpeg/tests/test_ffmpeg.py _________________
> ffmpeg/tests/test_ffmpeg.py:29: in <module>
> subprocess.check_call(['/nix/store/6a5nr567sb4a36lisa6gydpp3bfij1vv-ffmpeg-8.0-bin/bin/ffmpeg', '-version'])
> /nix/store/h3l9h1vmbzvgs4x1ffl0pqbmzhlk89yl-python3-3.13.12/lib/python3.13/subprocess.py:419: in check_call
> raise CalledProcessError(retcode, cmd)
> E subprocess.CalledProcessError: Command '['/nix/store/6a5nr567sb4a36lisa6gydpp3bfij1vv-ffmpeg-8.0-bin/bin/ffmpeg', '-version']' died with <Signals.SIGKILL: 9>.
| 19:48:05 |
| Randy Eckenrode | Probably https://github.com/NixOS/nixpkgs/issues/208951. It’s concerning the problem seems to be getting worse. | 19:50:07 |
| jyap | thanks, i'll take a look | 19:52:32 |
| jyap | yeah it's similar to this issue where the fix is to disable tests https://github.com/NixOS/nixpkgs/issues/507531 | 19:58:05 |
| 11 Apr 2026 |
| Randy Eckenrode | Why can’t anything link when using the 26.4 SDK? | 00:43:03 |
| Randy Eckenrode | Oh, crap. | 00:44:20 |
| Randy Eckenrode | Apple dropped arm64 support. | 00:44:25 |
| Randy Eckenrode | The stubs only support arm64e. | 00:44:34 |
| Randy Eckenrode | Well, some of them only support it. libc++ still supports arm64, which may be a mistake. | 00:47:03 |
| Randy Eckenrode | Ugh, this sucks. | 00:47:06 |
| Randy Eckenrode | Is our SDK unpacking mangling the stubs? That somehow seems worse. | 00:53:10 |
| Randy Eckenrode | No, doesn’t look like. | 01:00:44 |
| Randy Eckenrode | * | 01:00:50 |
 emily | wait, what? wasn't the arm64e ABI not stable before? | 01:02:19 |
| emily | isn't it more likely that they just merged the symbol lists into one or something? | 01:02:28 |
| Randy Eckenrode | It was stabilized in macOS 26. | 01:05:11 |
| Randy Eckenrode | Many of the 26.4 headers do not include arm64-macos in the list of targets. | 01:05:28 |
| emily | but you can target way back with the macOS 26 SDK, right? 🤔 | 01:05:37 |
| emily | maybe we just need to switch to arm64e | 01:05:48 |
| Randy Eckenrode | Upstream LLVM doesn’t have all the changes needed to support it. In particular, you need to set the ABI version, which it doesn’t support. | 01:06:13 |
| Randy Eckenrode | There’s work in progress to add support, but it’s not something we could use now. | 01:06:31 |
| Randy Eckenrode | Somehow Xcode’s clang can link against arm64 without its being listed as a target. I don’t know how it’s doing that. Apple hasn’t released updated tapi sources for Xcode 26. I’m trying to see if maybe there are un-upstreamed LLVM TextAPI changes. | 01:07:37 |
| emily | I'm wondering if you can just duplicate the arm64e symbols for arm64 and it will all happen to work | 01:08:38 |
| Randy Eckenrode | Probably, but that will involve doing some post-processing on every tbd file. | 01:09:02 |
| Randy Eckenrode | And not all of them have this issue. libc++.tbd notably does not, which is how I was able to fully bootstrap with the 26.4 libc++ headers and stubs without encountering this issue. | 01:09:34 |
| emily | just like old times :) | 01:09:41 |
| Randy Eckenrode | * And not all of them have this issue. libc++.tbd notably does not, which is how I was able to fully bootstrap with the 26.4 libc++ headers and stubs without encountering this issue. | 01:09:43 |
