| 11 Apr 2026 |
 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 |
| emily | Randy Eckenrode: going to take a look at the pending PRs now. I take it you're targeting these refactors/bumps for before the freeze? | 15:13:44 |
| emily | the 26.4 bump seems like it might be… exciting :) | 15:14:21 |
| Randy Eckenrode | Yes. The source release refactor has no rebuilds. | 15:15:15 |
| Randy Eckenrode | Future SDK updates should be easier assuming Apple stops doing weird things. | 15:15:34 |
| emily | big assumption | 15:16:01 |
| emily | I'm looking into the ICU thing | 17:12:16 |
| emily | left a very long, rambly comment, apologies 😅 | 18:40:00 |
| emily | not 100% confident I figured out the best fix but I am at least a lot less confused by the observed behaviour now | 18:42:18 |
| Randy Eckenrode | I believe one of the .NET core
libraries links against it. The native AoT also links against it. | 18:43:24 |
| emily | it's all via dlopen, I traced it fully in my comment and also figured out the root cause of why ICU specifically causes the weird mixing | 18:44:53 |
