| 17 Jan 2026 |
 alexfmpe | * adding apple-sdk there causes -L to be passed with libiconv
$ echo $NIX_LDFLAGS
-liconv -L/nix/store/6nmmi317rg2bnybndbgc944dpg5cnl5a-libiconv-109.100.2/lib -L/nix/store/lgcr7kswpb1hap1vsjwrzzcqjks0xal6-libresolv-91/lib -L/nix/store/0x1fcnqb9lf6x3vcn53rxn7ijv7skg7y-libsbuf-14.1.0/lib -L/nix/store/fq0jizzyjkilz0rj3kvc1hskc7ry84ds-libutil-72/lib -L/nix/store/6nmmi317rg2bnybndbgc944dpg5cnl5a-libiconv-109.100.2/lib -L/nix/store/lgcr7kswpb1hap1vsjwrzzcqjks0xal6-libresolv-91/lib -L/nix/store/0x1fcnqb9lf6x3vcn53rxn7ijv7skg7y-libsbuf-14.1.0/lib -L/nix/store/fq0jizzyjkilz0rj3kvc1hskc7ry84ds-libutil-72/lib
| 17:57:32 |
| alexfmpe | so I guess...PR the apple-sdk addition and call it a day? | 17:57:45 |
 Randy Eckenrode | I think there is work (slowly) being done to add support upstream, but it’s slow going. | 17:57:56 |
| alexfmpe | makes it less broken afterall | 17:58:01 |
| Randy Eckenrode | * | 17:58:06 |
| Randy Eckenrode | I wouldn’t be surprised if whatever GNU is doing to generate their own headers is not compatible with recent SDKs and GCC. | 17:58:40 |
| Randy Eckenrode | Is this x86_64-darwin or aarch64-darwin? | 17:58:46 |
| Randy Eckenrode | AFAIK you need the aarch64-darwin patch set for compatibility with the SDK headers. We don’t apply it on x86_64-darwin for some reason. | 17:59:04 |
| alexfmpe | aarch64-darwin | 18:00:04 |
 emily | pretty sure we do | 18:00:27 |
| emily | we skip it on cross because it used to be broken but now it's not. I have local patches to clean that stuff up | 18:00:48 |
| emily | (are you doing cross?) | 18:01:01 |
| alexfmpe | not on the hello example, but that's what I wanted to do lol | 18:01:33 |
| alexfmpe | because ghc is acting up with clang when doing cross | 18:01:56 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/blob/fa3fde27c743fe15cdd1d027795e50dcdb741995/pkgs/development/compilers/gcc/patches/default.nix#L35-L42 | 18:02:23 |
| alexfmpe | (not nixpkgs specific) | 18:02:25 |
| Randy Eckenrode | I wonder if I should just copy swift-frontend and swift-driver into the swift package and call it a day. | 18:03:56 |
| Randy Eckenrode | They both do their own resource folder logic. | 18:04:10 |
| emily | maybe that's another thing I have patches for locally | 18:16:18 |
| Randy Eckenrode | … does the current swift-driver not support separate lib outputs? | 18:18:04 |
| Randy Eckenrode | This is what I did. I think I know where I can patch it in both places, but I don’t want to break things that might depend on the path being resolved to the original binary. swift-driver is also pretty small. swift-frontend is inexplicably large. | 18:38:56 |
| Randy Eckenrode | * This is what I did. I think I know where I can patch it in both places, but I don’t want to break things that might depend on the path being resolved to the original binary. swift-driver is also pretty small. swift-frontend is inexplicably large though. | 18:39:04 |
| Randy Eckenrode | Copy all the things and let the store optimizer sort it out. | 18:39:24 |
| emily | assuming most users will only need to download the final package it shouldn't have much impact | 18:41:13 |
| emily | we could copy the stdlib in too if necessary | 18:41:28 |
| emily | although that means targetPlatform evil | 18:41:46 |
| Randy Eckenrode | The problem is swiftc looks for its libraries in the path where it really is. | 18:42:12 |
| Randy Eckenrode | So if swiftc is a symlink, it will look in the swiftc package, but that package has no stdlib. | 18:42:34 |
| Randy Eckenrode | What I want is for it to look in the swift package that symlinks all the stuff together. | 18:42:52 |
| Randy Eckenrode | swiftc, swift-driver, swift-corelibs-xctest, swift-testing, (on Linux), swift-corelibs-foundation, etc. | 18:43:23 |
