| 8 Dec 2025 |
 Ihar Hrachyshka | I will update the issue they have later with the above, really cool stuff | 17:52:24 |
 emily | I suggest replacing LLAMA_INSTALL_VERSION with LLAMA_BUILD_NUMBER upstream | 17:52:26 |
| emily | that's a two line diff | 17:52:34 |
| Ihar Hrachyshka | would take me a lot longer, appreciate it | 17:52:37 |
| emily | and in fact we could just vendor this patch locally while waiting for upstream | 17:52:47 |
| emily | only infelicity is that if they ever do actual versions the ordering will be weird | 17:52:58 |
| emily | but I doubt anything actually cares about the value | 17:53:09 |
| emily | that will start failing when they go over 65536 commits too fwiw | 17:53:49 |
| emily | or well, start truncating | 17:53:54 |
| emily | I'm not convinced anything actually cares about the "current version" field of a library though | 17:54:29 |
 Randy Eckenrode | Many times projects just set junk versions. The versions for llbuild’s framework are 1 and 1. | 17:54:31 |
| emily | yeah | 17:54:48 |
| emily | so just dropping VERSION … would be another option | 17:54:54 |
| emily | but it'll change the filenames used on Linux | 17:54:58 |
| emily | well, and on macOS too | 17:55:05 |
| emily | -rwxr-xr-x@ 1 emily staff 608K 8 Dec 16:09 libmtmd.0.0.7325.dylib*
lrwxr-xr-x@ 1 emily staff 22B 8 Dec 16:09 libmtmd.0.dylib@ -> libmtmd.0.0.7325.dylib
| 17:55:11 |
| emily | aha | 17:55:20 |
| emily |
For shared libraries, the MACHO_COMPATIBILITY_VERSION and MACHO_CURRENT_VERSION properties can be used to override the compatibility version and current version respectively.
| 17:55:22 |
| emily | so another option is to simply add MACHO_CURRENT_VERSION 0 to both of these | 17:55:40 |
| emily | that will maintain the same filenames on both platforms but remove the field in the dylib that is already getting truncated and that probably nobody cares about | 17:55:59 |
| emily | that is probably what I would upstream as the minimal change | 17:56:08 |
| emily | if they start doing actual releases with normal numbers they could then start putting that information back in without messing up ordering | 17:56:25 |
| Randy Eckenrode | $ nix build '/nix/store/xdyf7irjmij4xjfrd9ph66icch3412r3-early-swift-driver-6.2.1.drv^*'
$ nix-store -qR ./result
/nix/store/8f7amxylm5vi21l00xissbb6d8l4icdl-ncurses-6.5
/nix/store/vzggzw92lznlk9s0730svz5rp7nvswww-zlib-1.3.1
/nix/store/b0ygrry710bgyzpys1vddj6b7vrhwq26-sqlite-3.51.0
/nix/store/9v8n0gszrih4zf158l881skfkh7gal01-swift-llbuild-6.2.1-lib
/nix/store/rl3ap69dwn3i9l4260k413227yk5499k-early-swift-driver-6.2.1-lib
/nix/store/w6zchw1mg284b1khn6k2wb2cdgklz73a-early-swift-driver-6.2.1
| 21:01:06 |
| Randy Eckenrode | Next up is swift-tools-support-core. I’m working on polishing the CMake builds, so they can be used as regular libraries. | 21:01:39 |
| 9 Dec 2025 |
| Randy Eckenrode | $ nix build '/nix/store/i53wmy3v3hd8phl8qm4zgnpi66b796sj-early-swift-driver-6.2.1.drv^*'
$ nix-store -qR ./result
/nix/store/czkz4fdz89h8kf1s0d4lzfcgjqny98fv-swift-tools-support-core-6.2.1
/nix/store/8f7amxylm5vi21l00xissbb6d8l4icdl-ncurses-6.5
/nix/store/vzggzw92lznlk9s0730svz5rp7nvswww-zlib-1.3.1
/nix/store/b0ygrry710bgyzpys1vddj6b7vrhwq26-sqlite-3.51.0
/nix/store/gglkzl9f5anf01k6nzlajfb03lczcd9k-swift-llbuild-6.2.1-lib
/nix/store/pv916rkkx8w494zps5rffsrxgk3ilql6-early-swift-driver-6.2.1-lib
/nix/store/4qwzh6c1hg8is0n96prfw93jxp5bfjzi-early-swift-driver-6.2.1
$ otool -L result/bin/swift-driver
result/bin/swift-driver:
/nix/store/pv916rkkx8w494zps5rffsrxgk3ilql6-early-swift-driver-6.2.1-lib/lib/swift/macosx/libSwiftDriverExecution.dylib (compatibility version 0.0.0, current version 0.0.0)
/nix/store/pv916rkkx8w494zps5rffsrxgk3ilql6-early-swift-driver-6.2.1-lib/lib/swift/macosx/libSwiftDriver.dylib (compatibility version 0.0.0, current version 0.0.0)
/nix/store/czkz4fdz89h8kf1s0d4lzfcgjqny98fv-swift-tools-support-core-6.2.1/lib/libSwiftToolsSupport.dylib (compatibility version 0.0.0, current version 0.0.0)
/nix/store/pv916rkkx8w494zps5rffsrxgk3ilql6-early-swift-driver-6.2.1-lib/lib/swift/macosx/libSwiftOptions.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 2420.0.0)
/usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 0.0.0)
/usr/lib/swift/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 120.100.0, weak)
/usr/lib/swift/libswiftDarwin.dylib (compatibility version 1.0.0, current version 0.0.0)
/usr/lib/swift/libswiftDispatch.dylib (compatibility version 1.0.0, current version 41.0.0)
/usr/lib/swift/libswiftIOKit.dylib (compatibility version 1.0.0, current version 1.0.0, weak)
/usr/lib/swift/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 8.0.0, weak)
/usr/lib/swift/libswiftXPC.dylib (compatibility version 1.0.0, current version 36.100.7, weak)
/usr/lib/swift/libswiftos.dylib (compatibility version 1.0.0, current version 1049.100.4, weak)
| 01:36:32 |
| Randy Eckenrode | Swift 6.2.2 is out. I should see how badly everything breaks …. | 02:19:35 |
| Randy Eckenrode | … why does Mesa depend on Swift? | 02:25:17 |
| Randy Eckenrode | I updated my KosmicKrisp branch. It’s getting closer to MoltenVK in terms of coverage. | 02:35:52 |
| Randy Eckenrode | My status for tonight is I got swift-llbuild and swift-tools-support-core building dylibs — somewhat similar to how Darwin toolchains do it. | 02:50:37 |
| Randy Eckenrode | Up next is Swift Compiler Driver once I finish rebuilding back up to having a bootstrap compiler. | 02:50:55 |
