| 8 Dec 2025 |
 toonn | I don't see an elegant solution honestly. | 17:30:39 |
 Ihar Hrachyshka | right. ideally upstream takes it seriously and bumps their minor to 0.1.XXXX and do the minor bump periodically to accommodate darwin. | 17:31:45 |
 emily | one week without meaningful progress has been our general rubric | 17:31:58 |
| Ihar Hrachyshka | otherwise we have to fake our own version numbers (just for darwin?) and risk divergence | 17:32:10 |
| emily | I think 3 weeks is more than enough notice on unstable | 17:32:26 |
| emily | (ofc the more load-bearing a package is the longer a period is reasonable, e.g. a default LLVM version bump that breaks Darwin is certainly not acceptable, but this is not a channel blocker etc.) | 17:32:49 |
| emily | they say it doesn't reproduce in CI. are we sure this is their problem? | 17:33:04 |
| Ihar Hrachyshka | one part of the equation is this package "versions" are really just trunk bumps | 17:33:07 |
| emily | if it's to do with the linker, perhaps it is because of us using the abandoned ld64? | 17:33:13 |
 Randy Eckenrode | Looks like a Mach-O limitation. | 17:33:32 |
| Ihar Hrachyshka | if that would be some real release process, it would look differently. the way it is, I'm asked to track their trunk at week notice. | 17:33:35 |
| emily | the person reporting the bug says they are using "a Mac 11", which implies probably pre-ld-prime Xcode | 17:33:43 |
| Ihar Hrachyshka | I triggered the build failure on my own mac, not some old version (15 or 26, can't remember) | 17:34:15 |
| emily | with Nixpkgs toolchain or Xcode? | 17:34:35 |
| emily | I think we need to understand why upstream's CI has no failure before we expect them to debug it as their issue: https://github.com/ggml-org/llama.cpp/actions/runs/20029229634/job/57433899126 | 17:34:56 |
| Ihar Hrachyshka | nixpkgs. yes it may be nix-specific, all others in the issue seem to talk about nix package | 17:35:14 |
| emily | well, we use a linker that is not the official default linker for macOS, that is deprecated upstream, and that has been more or less abandoned. | 17:36:09 |
| Randy Eckenrode | Source releases were updated. | 17:36:26 |
| emily | so if the build is failing because of ld64 not handling something that the Xcode linker can handle, it's our problem to solve, not llama.cpp's. | 17:36:29 |
| emily | ld64's? yeah, I saw it got some changes | 17:37:03 |
| emily | but it's certainly marked as deprecated, I'm assuming it's only getting very minimal maintenance before it goes away | 17:37:17 |
| emily | just saying that it's unreasonable to expect upstream to change their versioning format for a limitation of our old linker, if the linker Apple ships has no problem with it | 17:37:41 |
| Randy Eckenrode | I mean it looks like 26.1 releases dropped. | 17:37:44 |
| emily | oh cool | 17:37:49 |
| emily | anyway, I suggest checking what Xcode's linker produces in the resulting .dylib. we can always just patch the linker call downstream if necessary. | 17:38:48 |
| Randy Eckenrode | I want to switch Darwin to LLD, but it will take some work. | 17:39:16 |
| emily | I wouldn't want to accommodate a non-standard build environment that uses a deprecated linker with limitations that were fixed in the standard build environment, as an upstream | 17:39:30 |
| Randy Eckenrode | If you just wrap it, you get the UNIX ld interface, which nothing on Darwin expects. | 17:39:38 |
| emily | (https://github.com/AnacondaRecipes/llama.cpp-feedstock/pull/25/commits/eee704136b3a4076c8ba95125d0f033a64fd4caf wow, does Anaconda use ld64 too…?) | 17:40:23 |
| Randy Eckenrode | I tried it with my Swift work just for Swift, replacing the stdenv. | 17:40:41 |
