| 13 Jan 2026 |
 samasaur | and no support for any other package | 01:15:20 |
 Randy Eckenrode | There is some magic for Swift Syntax, but it seems to be really brittle. I was able to get it to parse a prebuilts entry in workspace-state.json, but SwiftPM didn’t do anything with it. | 01:15:31 |
| Randy Eckenrode | The more pressing need is figuring out how to discover the stdlib. | 01:15:47 |
| Randy Eckenrode | The current approach patches the compiler to find it at an arbitrary path, which isn’t very good for cross-compilation. | 01:16:19 |
 emily | env variable? | 01:16:35 |
| Randy Eckenrode | Ideally we could leverage the compiler’s ability to discover the stdlib relative to its location. | 01:16:48 |
| emily | preferably target-specific env variable | 01:16:48 |
| emily | though, yeah, avoiding patching at all is nicer | 01:17:01 |
| emily | can we just symlink the compiler and the stdlib nearby? | 01:17:11 |
| Randy Eckenrode | That’s what I want to do, but I also want them to be discoverable by the linker. | 01:18:28 |
| Randy Eckenrode | How does it work on Linux? Does linking with a .so at some path automatically set up the rpath? | 01:18:44 |
| Randy Eckenrode | It makes me wonder what even the point of the patch is if the linker will handle things for us. | 01:20:35 |
| Randy Eckenrode | “It also fixes the output of swift -frontend -print-target-info, which SwiftPM uses to set the rpath on Linux.”
If the .sos are in the normal place, won’t the linker take care of this for us?
| 01:21:27 |
| emily | is this about one of our existing patches? | 01:22:38 |
| emily | I figured you would have just thrown all of those away… | 01:22:45 |
| emily | I assumed -L would add to the rpath or such. | 01:23:42 |
| emily | not sure exactly how it works. | 01:23:44 |
| Randy Eckenrode | The separate lib patch. | 01:24:10 |
| emily | oh, our wrapper does it. | 01:24:37 |
| emily | # Three tasks:
#
# 1. Find all -L... switches for rpath
| 01:24:40 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/blob/c3d8909996f4f24ed7cbeeee7600ee75c873fd04/pkgs/development/compilers/swift/compiler/patches/swift-separate-lib.patch | 01:24:50 |
| emily | that one is nonsense anyway | 01:25:10 |
| Randy Eckenrode | I assume the reason why that doesn’t work with Swift is the libraries are not in $out/lib, but I’ve taken to putting all of them there in my work. | 01:25:13 |
| Randy Eckenrode | So the linker should do the right thing. | 01:25:23 |
| emily | IIRC half of what's in $lib is not required at runtime | 01:25:25 |
| emily | and there's some dumb dependency too | 01:25:51 |
| Randy Eckenrode | I’ve got the stdlib build with only the host shared libraries. Build platform stuff is staying with the compiler. | 01:26:09 |
| Randy Eckenrode | So in theory you can make a cross-Swift using the new host’s stdlib. | 01:26:32 |
| Randy Eckenrode | But cross won’t work out of the box with my work. It doesn’t now, and I don’t want to spend time on it right now. | 01:26:50 |
| Randy Eckenrode | I want to get Swift updated to 6.2.x with the rewritten package set, so I can switch gears back to Darwin for a bit. | 01:27:39 |
