| 25 Nov 2024 |
 p14 | That would be super cool. | 20:01:26 |
 emily | it's a shame that Unix ended up with this model where you have the runtime executable code and the linker ABI information in the same file, even though the compilation stage just doesn't care about the former at all | 20:01:54 |
| emily | the LLVM stub stuff is cool but it still essentially involves making hack ELF files to get tools to cooperate | 20:02:10 |
| p14 | John Ericson: i am excited to see work being thought about in the CA world. Really want to see this happen. | 20:02:21 |
| emily | macOS is ahead here – all the system libraries ship as YAML stub files that just list symbols in the official SDKs | 20:02:26 |
 trofi | In reply to @Ericson2314:matrix.org
I know finally understand what trofi was doing long ago in mkDerivation, and I agree that's the right thing to do for now Restored as https://github.com/NixOS/nixpkgs/pull/359098 :) | 20:14:41 |
 John Ericson | trofi: I think it can go directly to master, no? | 20:21:58 |
| John Ericson | not an official mass rebuild :) | 20:22:02 |
| p14 | In reply to @emilazy:matrix.org
would be cool to see your prototype https://gist.github.com/pwaller/31501f4068dfd0f94d867a1aa2cc0be8 | 20:36:01 |
| p14 | Annoyingly, can't put a directory in a gist, so settled on txtar instead. | 20:36:42 |
| p14 | The next trick will be to write this as an overlay, stdenvStage, or minimal patch against nixpkgs that does this to everything through arcane magic. | 20:37:25 |
| emily | I think you can – just add multiple files and it can be git cloned? | 20:37:34 |
| emily | we need some of this ANSI art in Nixpkgs | 20:37:39 |
| p14 | :D | 20:37:44 |
| p14 | You can put multiple files in, but not multiple directories. They get rejected by the git remote when you try to push them. | 20:37:59 |
| p14 | It was a fun little exercise but I can see there is quite a bit more work involved even when it comes to handling a single package. I'm actually not sure what to reach for to do something as simple as replacing nix paths in a binary; patchelf obviously is the thing to reach for when the strings appear in a specific place, but substituteAll barf'd on the null characters. | 20:39:53 |
| emily | I think Nixpkgs just uses sed for that | 20:40:30 |
| emily | in e.g. remove-references-to | 20:40:33 |
| p14 | Yeah, I thought so too, but I had some issues. I may not have hit it with the stick hard enough. | 20:40:47 |
| emily | you might also want to add an example of a build tool that depends on a library, to screw all the nice properties up | 20:40:54 |
| p14 | Well yeah; that's going to be the interesting/unfortunate case. I was thinking of that in the context of 'glibc' upgrades. ISTM that if you have to relink users of glibc, this means relinking the compiler, which then means everything that uses the compiler has to be rebuilt. | 20:41:38 |
| emily | yes | 20:42:05 |
| emily | the alternative is letting buildPackages drift etc., which isn't fun | 20:42:21 |
| emily | ultimately compiler upgrades are compiler upgrades. what I worry about is more, like, random build stuff that has OpenSSL dependencies | 20:42:43 |
| emily | for hashing or because it has network functionality we don't use or – whatever | 20:42:51 |
| p14 | So I was wondering about how you could make stdenv.mkDerivation do what the gist above does under the hood. Perhaps by modifying how getDev works; I think this would be enough to handle buildInputs. Then you'd need some way to make packages 'be observed as' the relink. | 20:44:42 |
| p14 | Any bright ideas about where such logic could hide? | 20:44:54 |
| emily | it's basically splicing in miniature I think. | 20:46:10 |
| emily | the hard part is making relinking happen. | 20:46:21 |
| p14 | That's about where I was up to :) | 20:46:24 |
