17 Sep 2025 |
Randy Eckenrode | Time to update Xcode to see what versions of things it has. | 01:49:46 |
Randy Eckenrode | Is there a 15.6 SDK? | 01:52:18 |
emily | not some days ago when I did the update at least | 01:52:47 |
emily | iirc libc++ is 20.* in 26 SDK | 01:52:56 |
Randy Eckenrode | https://github.com/apple-oss-distributions/webdavfs/commit/77cce7d78f880b4f005ba37fdc03958b88d55c9e | 01:53:56 |
Randy Eckenrode | lol? | 01:53:57 |
emily | btw https://github.com/NixOS/nixpkgs/pull/443314 | 01:55:19 |
emily | one of the few LLVM 21 things left I think | 01:55:51 |
emily | most stuff has been merged by now | 01:56:02 |
Randy Eckenrode | I saw that. I figured since it was sourced from my branch, I’m probably not the right person to review. | 01:56:04 |
emily | technically I changed it 😆 | 01:56:12 |
Randy Eckenrode |
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld-classic -v
@(#)PROGRAM:ld-classic PROJECT:ld64-956.6
BUILD 16:28:55 Aug 11 2025
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em armv8m.main armv8.1m.main
LTO support using: LLVM version 17.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 17.0.0 (tapi-1700.3.8)
| 01:57:36 |
emily | dropped LLVM 17 before Apple | 01:58:07 |
Randy Eckenrode | Apple is still updating ld64. I thought it was supposed to be removed? | 01:58:26 |
Randy Eckenrode | $ clang ~/Developer/test.c -arch arm64e -o test
$ file test
test: Mach-O 64-bit executable arm64e
$ ./test
3
$ cat test.c
#include <stdio.h>
int main() {
printf("%lu\n", sizeof(int));
}
| 02:00:28 |
Randy Eckenrode | Is the arm64e ABI finally stable? I’m on macOS 26.0 with SIP enabled. | 02:00:48 |
Randy Eckenrode | $ clang --version
Apple clang version 17.0.0 (clang-1700.3.19.1)
Target: arm64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
| 02:01:21 |
Randy Eckenrode | The Clang version really doesn’t make sense anymore. | 02:01:29 |
Randy Eckenrode | $ file test
test: Mach-O 64-bit arm64e (caps: PAC01) executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
| 02:07:23 |
Randy Eckenrode | $ file test2
test2: Mach-O 64-bit arm64e 00) executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
| 02:07:36 |
Randy Eckenrode | test2 was compiled with LLVM 19 from nixpkgs. It seems there is a new, stable arm64e ABI. | 02:07:53 |
Randy Eckenrode | https://github.com/llvm/llvm-project/pull/104650 | 02:08:22 |
Randy Eckenrode | From what I can tell, Apple hasn’t yet upstreamed the v1 ABI yet. | 02:16:41 |
samasaur | I'm pretty sure this would not work. From what I remember when I was messing around with nix-built Swift packages, the SDKs need to match or all libraries from the SDK give you an error about being built with a different version of Swift | 02:17:39 |
Randy Eckenrode | They give you that error, but the real error is usually something else. | 02:18:43 |
Randy Eckenrode | But right now, just getting my branch updated again and splitting things up is my priority. | 02:19:24 |
samasaur | This is ideally true though I remember back when Swift 5 running the Swift 4.2 language mode did not exhibit the same behavior as Swift 4.2 itself (or maybe it was 4.2 emulating 4 vs 4 itself? it's been a while) | 02:19:52 |
Randy Eckenrode | Apple only ships Swift 6.x. They don’t ship a Swift 5 compiler. | 02:20:17 |
samasaur | sure, and I'm not even against going from 5 to 6. I just mean that the language mode solution has not been perfect in the past | 02:21:06 |
Randy Eckenrode | I believe there are some things available to Swift 5 code, but the breaking language features require switching your modules to Swift 6. | 02:21:14 |