| 13 Apr 2026 |
viraptor | Hmmm... It's just processing a plistxml to generate some scaffolded interfaces. "How hard could that be" feeling is growing... | 12:38:37 |
viraptor | * | 12:39:10 |
Randy Eckenrode | I can’t make progress on the ICU issue until I resolve the issue with linking the 26.4 SDK using ld64. | 13:32:22 |
ankarhem | Do you know if there’s some workaround we can do locally for dotnet until it’s properly fixed? | 13:43:33 |
toonn | Applying Randy's PR is probably the best workaround IMO. | 13:47:24 |
Randy Eckenrode | That’s probably the best approach right now. | 13:47:59 |
Randy Eckenrode | I can rebase my changes on master, but I won’t be able to do that until lunch. I’m currently on my staging/Swift branch. | 13:53:42 |
niklaskorz | I looked into the idea of merging the normal icu package's dylibs into one libicucore.dylib this morning, but:
- that requires rebuilding anyway because it has to be built with symbol renaming disabled for programs that expect libicucore.dylib (either that or dotnet has to be patched to not disable icu symbol renaming on macOS)
- with symbol renaming disabled, I ended up with a "SIGBUS 10" crash
| 15:35:35 |
Randy Eckenrode | Symbol renaming being disabled should be the default. How were
you merging? | 15:36:53 |
Randy Eckenrode | I’m using clang++ to relink the dylibs. Make sure you also relink libicutu.dylb against libicucore.dylib. | 15:37:32 |
Randy Eckenrode | * I’m using clang++ to relink the dylibs. Make sure you also relink libicutu.dylib against libicucore.dylib. | 15:37:45 |
Randy Eckenrode | Finished my (attempted) build against master. It also crashed. Looking at the stack trace, it’s crashing in the same place. | 23:38:39 |
| 14 Apr 2026 |
viraptor | Is swbuild available somewhere for testing already? I'm assuming you weren't using the host one in that PR. | 01:31:34 |
viraptor | * | 01:40:58 |
viraptor | * | 01:43:10 |
Randy Eckenrode | It’s in my swift-update-mk2 branch. | 02:10:26 |
| LogN changed their display name from LogN to LogN [unavailable @ CinemaCon -> 4/18]. | 04:03:07 |
eveeifyeve | Can you enable homebrew for multiple users or don't declare a user? | 09:53:07 |
eveeifyeve | Because I am writing my config using the dendritic pattern, I have a problem where I will require multiple users so I need it to be either user specific or global defination. | 09:54:18 |
eveeifyeve | * Because I am writing my config using the dendritic pattern, I have a problem where I will require multiple users so I need it to be either user specific or global definition. | 09:54:26 |
eveeifyeve | There isn't exact primaryUser in this case. | 09:54:58 |
viraptor | https://github.com/NixOS/nixpkgs/pull/509975 supports SVG now - give it a go? | 13:49:53 |
viraptor | Yet another one then: intent builder reimplemented https://github.com/NixOS/nixpkgs/pull/509997
(I'm still waiting on security to fix their alerts, so can't test it end to end with your PR, but individually it all works - may just need some PATH fun if it gets called with xcrun) | 15:11:56 |
viraptor | * | 15:14:41 |
eveeifyeve | Redacted or Malformed Event | 15:51:27 |
| 15 Apr 2026 |
Randy Eckenrode | I have made some progress on my 26.4 SDK issue. It appears that ld64 supports linking ABI-compatible dylibs of a different architecture (e.g., arm64e to your arm64 binary and x86_64 to x86_64h), but it does not appear that support extends to text-based stubs. Whether that’s something I broke or a feature that got added in a newer libtapi, I don’t know. | 01:23:24 |
Randy Eckenrode | As in, clang libarm64e.dylib foo.c -o foo works but clang libarm64e.tbd foo.c -o foo does not. | 01:26:07 |
Randy Eckenrode | Where libarm64e.tbd is generated from libarm64e.dylib. | 01:26:21 |
Randy Eckenrode | I tried updating ld64, but it’s still failing, so the issue is in libtapi. Lovely. | 01:48:28 |
Randy Eckenrode | I linked ld64 against libtapi from Xcode. It works. The fix has to be in libtapi. This sucks. | 02:11:12 |