| 8 Dec 2025 |
 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 |
 Ihar Hrachyshka | ack on obsolete linker, I didn't know of the difference. if that's the case then I think we should patch to something like 0.0.0001 or perhaps 0.0.<last-working-version> until linker is updated. | 17:40:49 |
| Randy Eckenrode | I do have as a goal for 26.05 to have pure LLVM bintools on Darwin. | 17:41:22 |
| Randy Eckenrode | The few things that need other tools can add them. | 17:41:37 |
| Randy Eckenrode | Ideally, no cctools or ld64 in the bootstrap, but that may not be possible. | 17:42:49 |
| emily | https://github.com/ggml-org/llama.cpp/blob/bde188d60f58012ada0725c6dd5ba7c69fe4dd87/src/CMakeLists.txt#L140 is the relevant line, fwiw | 17:43:22 |
| emily | we could probably just drop that on Darwin for now | 17:43:36 |
| emily | I'm guessing nothing really cares about the version | 17:43:43 |
| emily | maybe we should check whether LLD can handle this, though 🤔 | 17:43:58 |
| Randy Eckenrode | That line will set the current version in the dylib. | 17:43:58 |
| emily | we could always use LLD here if so | 17:44:05 |
| emily | (maybe not, I guess wrapping is a question) | 17:44:16 |
| emily | shion:/v/f/1/j/T/tmp.gRxduPvwNI
❭ clang -shared foo.c -current_version 0.0.7299 -o libfoo.dylib
foo.c:1:9: warning: non-void function does not return a value [-Wreturn-type]
1 | int a(){}
| ^
1 warning generated.
ld: warning: truncating -dylib_current_version to fit in 32-bit space used by old mach-o format
uh, that's fun :D
| 17:46:30 |
| Ihar Hrachyshka | what's "old mach-o" and is there a "new" one... | 17:47:43 |
| emily | someone should check whether the Xcode toolchain is truncating it too | 17:48:18 |
| emily | shion:/v/f/1/j/T/tmp.gRxduPvwNI
❭ otool -l libfoo.dylib | rg -A 5 LC_ID_DYLIB
cmd LC_ID_DYLIB
cmdsize 40
name libfoo.dylib (offset 24)
time stamp 1 Thu Jan 1 01:00:01 1970
current version 0.0.255
compatibility version 0.0.0
| 17:48:20 |
| emily | oh they have official binaries. how convenient | 17:48:52 |
