| 13 Nov 2024 |
 sterni | now everything's broken | 22:53:37 |
| sterni | you can't do native cross anymore, nixpkgs has become like the build systems it used to fight | 22:54:19 |
| sterni | like you have to pass crossOverlays = [ (self: super: {}) ] which is just stupid | 22:57:45 |
 emily | by "native cross", you mean always-cross? | 23:03:07 |
 Artturin | We need to resurrect https://github.com/NixOS/nixpkgs/pull/238331 | 23:03:12 |
| emily | I'd rather just do always-cross always. | 23:03:26 |
| sterni | Artturin: indeed because you can't reintroduce native cross now because of function equality or at least it'd be very weird | 23:11:04 |
| sterni | hmm scratch that actually it'd probably just be like before | 23:11:52 |
| sterni | emily: well just when you request it so not always | 23:12:07 |
| emily | yeah, but it should be always :) | 23:12:19 |
| 14 Nov 2024 |
 p14 | @sterni I am afk from writing on github but:
I wonder if the header has any target specific CPP?
I think the answer is negative. Logically, if the clang derivation is not varying according to targetPlatform, it cannot. | 16:54:33 |
| p14 | (Re https://github.com/NixOS/nixpkgs/pull/355532#issuecomment-2476054093) | 16:55:03 |
| emily | I think sterni meant the libbfd headers | 16:55:09 |
| emily | which is a target-sensitive derivation | 16:55:14 |
| emily | though the .src isn't of course | 16:55:27 |
| p14 | I took those from source, not build. | 16:55:29 |
| emily | yeah | 16:55:42 |
| sterni | indeed, the question would be if we can just build LLVMgold.so unconditionally or whether it will fail sometimes due to the header | 16:55:43 |
| emily | you do need to adjust the default of the flag that turns it on | 16:55:50 |
| emily | I think that was the intention of the PR | 16:55:53 |
| emily | and p14 just missed that our default is target-specific | 16:55:58 |
| emily | presumably it builds fine on a Darwin host at present as you can do cross to Linux, so I think doing it unconditionally should be okay | 16:56:37 |
| emily | the tar thing is weird but I don't have a better idea | 16:56:44 |
| emily | it should maybe move to libbfd itself | 16:56:51 |
| emily | i.e. libbfd.plugin-api | 16:56:57 |
| emily | so that it is clear what interface we commit to there | 16:57:05 |
| emily | "-DLLVM_BINUTILS_INCDIR=${libbfd.plugin-api}/include" feels nicer | 16:57:38 |
| p14 | Seems a reasonable suggestion! I would appreciate it on-PR so I don’t forget when I come back to it.
With respect to separating LLVMgold.so into a different derivation, I am not sure of the value of that. The build system archania and subsequent potential for breakage required to do it does not seem worth the hassle. | 17:00:05 |
| emily | I don't think that was suggested, was it? | 17:00:19 |
| emily | ah, sterni did | 17:00:35 |
