| 4 Dec 2025 |
 Randy Eckenrode | Bootstrapping Swift from source seems like doing it on hard mode. | 23:14:20 |
 toonn | Doesn't everything? Guix has GCC all the way from Mes but I don't think Nixpkgs does anything similar? | 23:15:45 |
| toonn | I think with Swift the idea was more that since it's so recent it wasn't as difficult? | 23:16:23 |
| Randy Eckenrode | nixpkgs doesn’t have it yet, but there is work being done on a minimal bootstrap. | 23:16:35 |
| Randy Eckenrode | Swift assumes you have a Swift compiler handy. They restored building a C++-only bootstrap compiler, but it’s still buggy, and it doesn’t appear to be an intended bootstrap path on Darwin. | 23:17:43 |
| Randy Eckenrode | * | 23:17:54 |
| 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 |
