| 31 Oct 2025 |
 niklaskorz | but it's not only that crate | 13:30:50 |
| niklaskorz | also the ring crate that is a very common dependency | 13:30:58 |
| niklaskorz | notably the failing linker invocation has these args that I would suspect should not be there when producing a linux elf binary: | 13:31:52 |
| niklaskorz | "-liconv" "-lSystem" "-lc" "-lm" "-arch" "arm64" "-mmacosx-version-min=11.0.0"
| 13:31:54 |
| niklaskorz | oh wait, what's failing is compiling the build script itself :o | 13:37:07 |
| niklaskorz | ok so then it makes sense that is being compiled for the build platform | 13:37:26 |
| niklaskorz | hm but in that case emily's original suggestion is likely the solution and I just added it in the wrong place | 13:38:30 |
| niklaskorz | at least I'm now certain it fails for cc crate with feature parallel enabled | 13:52:59 |
 Randy Eckenrode | Shouldn’t the build platform CC have the right SDK and stuff? It should be using the fallback SDK. | 13:55:02 |
| Randy Eckenrode | Oh, but it’s not finding the propagated inputs probably. If you add just libiconv, does it work? | 13:56:53 |
| Randy Eckenrode | I hate how we do dependencies so much. | 13:57:02 |
| Randy Eckenrode | Like with a bunch of wrapper stuff and Bash to find propagated dependencies. | 13:57:50 |
| niklaskorz | no, already tried that :/ | 13:58:44 |
| Randy Eckenrode | Maybe we should symlink the dylibs or add text-based stubs for them instead of propagating them. I can do that for 26.05. It seems too risky for 25.11. | 13:59:08 |
| Randy Eckenrode | I don’t think adding an SDK for the build platform is the right solution. | 13:59:31 |
| Randy Eckenrode | * | 13:59:46 |
| Randy Eckenrode | Or maybe it is but only when Darwin is the build. 🤔 | 14:00:25 |
| niklaskorz | uploaded the minimal reproducer here: https://github.com/niklaskorz/nix-rust-cross-cc | 14:00:29 |
 K900 | https://www.lunarg.com/lunarg-achieves-vulkan-1-3-conformance-with-kosmickrisp-on-apple-silicon/ wow | 15:05:43 |
 emily | we should just add apple-sdk to extraNativeBuildInputs I'm pretty sure | 15:43:10 |
| emily | it's redundant on native but the right thing for cross | 15:43:19 |
 Ihar Hrachyshka | is there a ready module for ssh-agent like the one in hm but launchd compatible? | 22:11:55 |
| 1 Nov 2025 |
 samasaur | https://www.swift.org/build-and-packaging-workgroup/ | 00:19:43 |
| samasaur | seems like that workgroup is not actually about packaging swift itself but it's still nice that there is now an actual group working on the build tooling | 00:20:39 |
| samasaur | we technically fall under this responsibility:
work with the community to support tooling outside the Swift project
| 00:21:44 |
| samasaur | though that is a generous reading on my part | 00:21:54 |
| Randy Eckenrode |
Decisions about how components of the Swift toolchain itself are built and distributed fall outside the workgroup’s charter.
| 00:22:11 |
| samasaur | hmm | 00:22:47 |
| Randy Eckenrode | It seems like this is about build system integration and how to help them with things like dependency resolution? | 00:23:07 |
| samasaur | so (if helpful at all) would be more helpful for your swift package set work, perhaps? | 00:23:24 |
