| 11 Apr 2026 |
 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 |
| emily | I suspect dlopen makes it easier to expose the issue here but isn't the root cause per se | 18:45:34 |
| Randy Eckenrode | The reason why we don’t follow Apple’s logic is to reuse our existing ICU derivation and potentially link it like a normal ICU. We also need the separate dylibs for the tests. | 18:48:13 |
| Randy Eckenrode | The C++ ABI isn’t stable. We can’t use normal ICU because Apple has its own patches. It also requires unversioned symbols, which is not how we build ICU. | 18:51:58 |
| Randy Eckenrode | * | 18:52:49 |
| Randy Eckenrode | We can’t use normal ICU because Apple has its own patches. It also requires unversioned symbols, which is not how we build ICU. | 18:52:52 |
