| 11 Apr 2026 |
 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 |
| Randy Eckenrode | I think it’s actually linking the arm64 binaries to the arm64e system libraries. | 01:26:24 |
| Randy Eckenrode | https://github.com/lelegard/arm-cpusysregs/blob/main/docs/arm64e-on-macos.md | 01:28:17 |
| Randy Eckenrode | It links with LLD but not with ld64. That’s helpful I guess. | 02:33:30 |
| Randy Eckenrode | Using LLD to link file_cmds works as a workaround. | 02:49:23 |
| Randy Eckenrode | The only source release left to finish updating is network_cmds. I’ll circle back to the SDK linking issue later. | 03:12:04 |
 niklaskorz | Apparently projects are starting to use Xcode 26's actool now to construct the new app icon format compiled to Assets.car, I wonder what we can do to accomodate that in nixpkgs... | 08:45:48 |
| niklaskorz | the actool in xcbuild does not seem to be able to handle the new icon input format or the car output format | 08:49:06 |
| niklaskorz | oh huh we have a python based re-implementation in nixpkgs already | 08:50:16 |
| niklaskorz | added three weeks ago, great timing 😄 | 08:51:42 |
| niklaskorz | doesn't seem to support SVGs yet unfortunately, mhm | 08:52:45 |
