| 13 Jan 2026 |
 Randy Eckenrode | If I can, I can revisit using custom helper hooks I guess. I hate hooks because Bash sucks, and debugging them sucks. | 01:12:51 |
| Randy Eckenrode | More pressing right now is how exactly to handle stdlib discovery. | 01:14:38 |
 emily | that would be nice for sure. what was the issue with that again? | 01:14:38 |
| Randy Eckenrode | It requires figuring out how it works and (probably) patching SwiftPM to allow it. | 01:14:56 |
 samasaur | aren't they only recently officially supported for swift-syntax only? | 01:15:14 |
| 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 |
