| 27 Nov 2025 |
Randy Eckenrode | No, they’re removed to limit what we’re distributing from the SDK to headers and stubs since those are arguably necessary for interoperability. Most of those man pages should be obtainable from the source releases. | 20:41:31 |
Randy Eckenrode | We could possibly smuggle them in via the empty darwin.libSystem derivation. | 20:41:59 |
| 28 Nov 2025 |
Randy Eckenrode | I’ve picked my Swift work back up. I’m trying to make the versioning of the LLVM fork more accurate to what Apple uses. The source is LLVM 19.1.5, but the version reported is 17.0.0. That’s probably going to make dealing with the overrides a lot of fun. | 16:27:47 |
Randy Eckenrode | The new, scope-based LLVM is so much nicer to override. There’s still jank, but I don’t have to do anything to handle build vs. host vs. target packages.
(llvmPackages_19.override {
officialRelease = {
version = "19.1.5"; # From https://github.com/swiftlang/llvm-project/blob/swift-$swiftVersion-RELEASE/cmake/Modules/LLVMVersion.cmake
};
monorepoSrc = fetchFromGitHub {
owner = "swiftlang";
repo = "llvm-project";
tag = "swift-${lib.getVersion swift}-RELEASE";
hash = "sha256-DahdGT8VMBOXuwfhtXIJGFJmmhzzoQ6NdpU2CDs5B/s=";
};
otherSplices = generateSplicesForMkScope [
"swiftPackages"
"llvmPackages"
];
}).overrideScope
(
_: prev: {
version = "17.0.0"; # From https://github.com/swiftlang/swift/blob/swift-$swiftVersion-RELEASE/utils/build_swift/build_swift/defaults.py#L51
}
)
| 17:26:02 |
Randy Eckenrode | * The new, scope-based LLVM is so much nicer to override. There’s still jank, but I don’t have to do anything to handle build vs. host vs. target packages.
let
swiftlangLlvmVersion = "17.0.0"; # From https://github.com/swiftlang/swift/blob/swift-$swiftVersion-RELEASE/utils/build_swift/build_swift/defaults.py#L51
llvmVersion = "19.1.5"; # From https://github.com/swiftlang/llvm-project/blob/swift-$swiftVersion-RELEASE/cmake/Modules/LLVMVersion.cmake
in
(llvmPackages_19.override {
officialRelease = { version = llvmVersion; };
monorepoSrc = fetchFromGitHub {
owner = "swiftlang";
repo = "llvm-project";
tag = "swift-${lib.getVersion swift}-RELEASE";
hash = "sha256-DahdGT8VMBOXuwfhtXIJGFJmmhzzoQ6NdpU2CDs5B/s=";
};
otherSplices = generateSplicesForMkScope [
"swiftPackages"
"llvmPackages"
];
}).overrideScope
(
_: prev: {
version = swiftlangLlvmVersion;
release_version = llvmVersion;
}
)
| 17:30:48 |
Randy Eckenrode | The weird version overrides are because of the way LLVM captures the version. | 17:31:14 |
Randy Eckenrode | I want the package version to match the one advertised by Swift. Ideally, I could it to build LLVM, but that would really break the patches. | 17:32:44 |
Randy Eckenrode | * | 17:32:52 |
Randy Eckenrode | * | 17:33:15 |
Randy Eckenrode | (This means the Swift clang will print 19.1.5 for its version instead of 17.0.0.) | 17:34:26 |
samasaur | exciting! | 20:44:08 |
samasaur | do let me know if i can help at all | 20:44:12 |
Sarah Clark | I have a weird build error that I'm trying to fix. python3Packages.torchtune crashes in importsCheckPhase when it imports python3Packages.sentencepiece on Darwin. I've confirmed that other python packages that depend on sentencepiece fail in the same way, but not if it's only used as a check dependency. The final weirdness: nix-build of sentencepiece picks up a prebuilt package, but calling it with --check shows a non-deterministic build. | 21:05:19 |
Sarah Clark | Console.app is how I first depetermined its sentencepiece | 21:05:51 |
Sarah Clark | * Console.app is how I first determined it's sentencepiece that's failing | 21:07:08 |
Sarah Clark |
| 21:12:23 |
Sarah Clark | * error: derivation 'rj3n6mm11f90ssv0az0aplkiy9b2s48l-python3.13-sentencepiece-0.2.1.drv' may not be deterministic: outputs differ
output '/nix/store/cpjk1gyzyz6j18jxfpsswdd0rggyzjah-python3.13-sentencepiece-0.2.1' differs | 21:12:29 |
Sarah Clark | * error: derivation 'rj3n6mm11f90ssv0az0aplkiy9b2s48l-python3.13-sentencepiece-0.2.1.drv' may not be deterministic: outputs differ
output '/nix/store/cpjk1gyzyz6j18jxfpsswdd0rggyzjah-python3.13-sentencepiece-0.2.1' differs
| 21:24:35 |
Randy Eckenrode | That’s expected on Darwin. | 21:48:53 |
Sarah Clark | The non-deterministic build? | 22:03:27 |
Sarah Clark | Or the sentencepiece crash? (In which case I would mark Darwin as a bad platform) | 22:03:52 |
Randy Eckenrode | This. | 22:08:35 |
Sarah Clark | OK, so it's non-causal. | 22:09:25 |
Sarah Clark | Here's the import crash:
0 ??? 0x0 ???
1 libpython3.13.dylib 0x103b950d8 state_fini + 228
2 libpython3.13.dylib 0x103b92828 _sre_SRE_Pattern_match + 712
3 libpython3.13.dylib 0x1038a3cd0 method_vectorcall_FASTCALL_KEYWORDS_METHOD + 188
4 libpython3.13.dylib 0x1038938c8 PyObject_VectorcallMethod + 168
5 libpython3.13.dylib 0x1039f242c check_matched + 112
6 libpython3.13.dylib 0x1039eebb8 warn_explicit + 1368
7 libpython3.13.dylib 0x1039f120c do_warn + 176
8 libpython3.13.dylib 0x1039ee158 PyErr_WarnFormat + 108
9 libpython3.13.dylib 0x10395549c _PyType_FromMetaclass_impl + 3940
10 _sentencepiece.cpython-313-darwin.so 0x12a79e4a4 SwigPyPacked_TypeOnce() + 104
11 _sentencepiece.cpython-313-darwin.so 0x12a77e738 PyInit__sentencepiece + 1244
12 libpython3.13.dylib 0x103ab0c38 _PyImport_RunModInitFunc + 100
13 libpython3.13.dylib 0x103aac6e0 import_run_extension + 192
14 libpython3.13.dylib 0x103aaf490 _imp_create_dynamic + 536
15 libpython3.13.dylib 0x103916d54 cfunction_vectorcall_FASTCALL + 280
16 libpython3.13.dylib 0x103a46eb0 _PyEval_EvalFrameDefault + 13948
-------- RECURSION LEVEL 9
17 libpython3.13.dylib 0x103893dc4 object_vacall + 428
18 libpython3.13.dylib 0x103893ac4 PyObject_CallMethodObjArgs + 124
19 libpython3.13.dylib 0x103aaa164 PyImport_ImportModuleLevelObject + 3048
20 libpython3.13.dylib 0x103a3b90c builtin___import__ + 316
21 libpython3.13.dylib 0x103916e68 cfunction_vectorcall_FASTCALL_KEYWORDS + 148
22 libpython3.13.dylib 0x103a46eb0 _PyEval_EvalFrameDefault + 13948
-------- RECURSION LEVEL 8
| 22:09:42 |
Sarah Clark | Looking through sentencepiece's issues, they finger SWIG as the culprit (potentially fixed in SWIG 4.4.0). There may be a patch to apply in the meantime without bumping SWIG. | 23:20:51 |
| 29 Nov 2025 |
Sarah Clark | I'll just link the ongoing saga here https://github.com/NixOS/nixpkgs/issues/466092 | 00:41:37 |
Randy Eckenrode | ninja: error: 'stdlib/public/core/SwiftMacros', needed by 'stdlib/public/core/OSX/arm64/Swift.o', missing and no known rule to make it
🤨
| 01:13:02 |
Randy Eckenrode | Oh, you have to explicitly disable SWIFT_ENABLE_SWIFT_IN_SWIFT now to get the C++-only compiler. | 01:30:53 |
Randy Eckenrode | /nix/var/nix/builds/nix-build-swift-6.2.1.drv-0/b/swift/stdlib/toolchain/Compatibility56/include/Concurrency/VoucherShims.h:73:3: error: 'os_release' is only available on macOS 10.10 or newer >
| 02:27:20 |
Randy Eckenrode | Looks like I’m also hitting unguarded availability errors. 🫠 | 02:27:50 |