| 20 Jun 2025 |
 emily | here | 22:41:16 |
| emily | it's something I've thought about before, there are some tricky issues I outlined, I expect somewhat invasive patching across the tree would be necessary, but the initial hurdles are more writing loader code etc. | 22:41:52 |
| emily | I think it would be feasible but hard (and some packages may never work) | 22:42:19 |
| emily | I see this came up as DT_INTERP in the doc. I think you can just solve the problem by avoiding the kernel's code for it as I outlined earlier. | 22:43:02 |
| emily | IIRC #!/usr/bin/env -S is not portable wrt macOS so may not be a good solution for shebangs. | 22:43:44 |
| emily | might be workaroundable. | 22:43:58 |
 John Ericson | oh my bad | 22:44:08 |
| John Ericson | I was scrolling around and didn't see it yet | 22:44:14 |
| John Ericson | with the static PIE? | 22:45:56 |
| John Ericson | that does sound nice | 22:46:14 |
| John Ericson | I'm hoping if we actually do it, we can petition POSIX to standardize more $ORIGIN | 22:46:42 |
| John Ericson | so the cure gets better, longer term | 22:46:51 |
| emily | you just need loader code that resolves out the interp path and does exec. hopefully. unless that doesn't quite do the right thing in which case you need to load the interp into memory and jump into it, which would be awful | 22:47:17 |
| emily | anyway it's definitely prototypeable I think and I've toyed with the idea but it'd take a lot of time and not sure the appetite for the requisite patching would be there in Nixpkgs | 22:47:58 |
| John Ericson | I have to leave now, but perhaps the first thing to pay for is some sort of demo to gauge feasibility / unseamliness of hacks | 22:48:05 |
| John Ericson |
not sure the appetite for the requisite patching would be there in Nixpkgs
The hope for that is to gameify it a bit with "are we relocatable yet?" etc.
| 22:48:39 |
| John Ericson | I am more confident on that part, if the initial prototype works, and it takes less skill to do the patching using previously-invented techniques than come up with the techniques | 22:49:32 |
| emily | well the problem is that many ecosystems may extensively use absolute paths | 22:51:45 |
| emily | e.g., in rigid non-programmable data formats | 22:51:52 |
| emily | so it is possible that it would require extensive patching that would be a maintenance burden for updates, in the case that upstream is not interested in changing that | 22:52:30 |
| John Ericson | @emilazy:matrix.org so I view this push as kind of trying to get C libraries for FFI to work | 23:01:19 |
| John Ericson | Like make us the go-to way to build the native deps for python packages or whatever | 23:02:13 |
| John Ericson | Or static executables | 23:02:46 |
| John Ericson | If whole systems a la NixOS fail to relocate, that's not ideal but it doesn't need to be fatal for that use-case | 23:17:33 |
| 22 Jun 2025 |
 tobim | Redacted or Malformed Event | 05:05:32 |
| tobim | Redacted or Malformed Event | 05:05:33 |
| John Ericson | In reply to @emilazy:matrix.org
IIRC #!/usr/bin/env -S is not portable wrt macOS so may not be a good solution for shebangs. https://ss64.com/mac/env.html actually the macOS env looks more powerful | 05:57:26 |
| John Ericson | Any chance we can get these features in coreutils? | 05:57:44 |
| John Ericson | Then we don't need a shim exe, because we can just expand an environment variable | 05:58:07 |
 p14 | emily: Tristan Ross: Can we entertain merging [0] as-is since it fixes a regression? The question of providing a "fake libgcc" is something requiring further development/enablement. https://github.com/NixOS/nixpkgs/pull/417354 | 10:44:19 |
