| 4 Dec 2025 |
 toonn | Self-hosting is fairly recent for Swift though, no? | 23:18:59 |
 Randy Eckenrode | I did eventually get the point of having a functional enough compiler to build a full Swift. I just have to remember from last time how I solved that @_noLock error. | 23:19:04 |
| Randy Eckenrode | The Swift Compiler Driver is at least five years old, but it’s not required (yet). Macros were the first time a Swift compiler was required for the bootstrap. They’re only a couple of years old. | 23:27:21 |
| Randy Eckenrode | But in a couple of years Swift went from only needing a C++ compiler to also needing a Swift compiler. | 23:27:51 |
| Randy Eckenrode | Writing Swift in Swift makes sense, but it makes a fully source-based bootstrap difficult (especially with how annoying it is to build). | 23:29:14 |
| Randy Eckenrode | I could do Swift 5.10.1 via a private scope the compiler uses to build, but I’d also have to pin the SDK version to make it happen. | 23:30:45 |
| Randy Eckenrode | * | 23:31:00 |
| 5 Dec 2025 |
| Randy Eckenrode | I think I disabled the bootstrapping mode, which isn’t supported anymore. | 04:05:49 |
| Randy Eckenrode | If I forcibly replace the bootstrapping0 compiler with the one from the bootstrap compiler, it works. That’s not very reassuring. | 04:39:09 |
 kfiz | Meh.
| 07:13:24 |
| kfiz | * Meh.
error: builder for '/nix/store/ixgbybg1is313l7vwv0vizdkcag16k1w-dovecot-2.4.2.drv' failed with exit code 2;
last 25 log lines:
> /nix/store/rrjy7x4jpxp92gs1prpbg79ng0mcl5hj-apple-sdk-14.4/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_string.h:62:9: note: previous definition is here
> 62 | #define memcpy(dest, ...) \
> | ^
> 1 warning generated.
> 1 warning generated.
> CCLD libcharset.la
> CCLD test-charset
> Undefined symbols for architecture arm64:
> "_iconv", referenced from:
> _iconv_charset_to_utf8_reset in libcharset.a(charset-iconv.o)
> _iconv_charset_to_utf8 in libcharset.a(charset-iconv.o)
> (maybe you meant: _charset_iconv)
> "_iconv_close", referenced from:
> _iconv_charset_to_utf8_end in libcharset.a(charset-iconv.o)
> "_iconv_open", referenced from:
> _iconv_charset_to_utf8_begin in libcharset.a(charset-iconv.o)
> ld: symbol(s) not found for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> make[3]: *** [Makefile:582: test-charset] Fehler 1
> make[3]: Verzeichnis „/nix/var/nix/builds/nix-build-dovecot-2.4.2.drv-0/b/dovecot-2.4.2/src/lib-charset“ wird verlassen
> make[2]: *** [Makefile:600: all-recursive] Fehler 1
> make[2]: Verzeichnis „/nix/var/nix/builds/nix-build-dovecot-2.4.2.drv-0/b/dovecot-2.4.2/src“ wird verlassen
> make[1]: *** [Makefile:733: all-recursive] Fehler 1
> make[1]: Verzeichnis „/nix/var/nix/builds/nix-build-dovecot-2.4.2.drv-0/b/dovecot-2.4.2“ wird verlassen
> make: *** [Makefile:575: all] Fehler 2
For full logs, run 'nix log /nix/store/ixgbybg1is313l7vwv0vizdkcag16k1w-dovecot-2.4.2.drv'.
| 07:13:54 |
| Randy Eckenrode | Upstream bug that detects but doesn’t properly link libiconv. You can try to figure out why or just add -liconv to NIX_LDFLAGS. | 11:32:56 |
|  adam 🎔 joined the room. | 11:47:36 |
| Randy Eckenrode | For 26.05, I want to try making darwin.binutils only have LLVM tools. I also want to try using LLD by default on Darwin. | 14:07:14 |
| Randy Eckenrode | I’m trying to build Swift using HOSTTOOLS. It gets up to the end, then ld gets stuck linking lib/swift/macosx/arm64/libswiftRegexBuilder.dylib. | 14:30:03 |
| Randy Eckenrode | * I’m trying to build Swift using HOSTTOOLS. It gets up to the end, then ld gets stuck linking lib/swift/macosx/arm64/libswiftRegexBuilder.dylib. That’s not good. | 14:30:22 |
 niklaskorz | In reply to @reckenrode:matrix.org
For 26.05, I want to try making darwin.binutils only have LLVM tools. I also want to try using LLD by default on Darwin. That'd pretty neat, but I recall you saying both lld and llvm install name tool had some compatibility issues? | 15:00:01 |
| Randy Eckenrode | Yes. I can add extra outputs to cctools that people can add when they really need those versions. The install_name_tool issue is probably not common. I don’t think many libraries use reexports. libiconv does due to historical accident. | 15:06:56 |
| niklaskorz | Cool! | 15:09:28 |
| Randy Eckenrode | I think the Swift issue is LTO. My hope is LLD is better. | 15:10:05 |
 emily | disclaimer for Gruber, but I have been happy to learn that the person who took responsibility for Liquid Glass and has otherwise overseen the decline in Apple UI design over the past decade has been replaced by an actual interface designer https://daringfireball.net/2025/12/bad_dye_job | 18:01:31 |
| emily | fingers crossed that macOS 27 will be the least worse macOS release compared to the previous version in years | 18:02:08 |
| Randy Eckenrode | I’m way behind on ATP, but Marco Arment has been ranting about Alan Dye for years. I look forward to (eventually) listening to the next episode. | 18:03:17 |
| Randy Eckenrode | Didn’t they say they were going to make it a Snow Leopard release? | 18:03:37 |
| emily | it sounds like we lucked into getting an expert who has been around for the entire century and everyone respects as the replacement rather than someone good at corporate politics | 18:04:33 |
| emily | hope it works out | 18:04:43 |
| emily | we could use a few Snow Leopards in a row at this point… | 18:04:56 |
 samasaur | yea rumor has it that it will be snow leopard–like. don't think we have heard anything official about it | 18:11:30 |
| Randy Eckenrode | Being back the cat names, and I might use them again instead of numbers. | 18:12:32 |
| samasaur | my favorite reaction to the dye news is that tweet at the end of the gruber article but my second favorite is this image: | 18:12:40 |
