| 12 Nov 2024 |
 sterni | In reply to @emilazy:matrix.org
well, ideally targetPlatform would be null so they would have no way of depending on it that doesn't make sense, you always have a target platform in a package set and Nix can figure out whether it needs rebuilding or not on its own | 12:19:58 |
| sterni | subtle problems are usually introduced elsewhere, so nulling it for some derivations isn't really solving anything | 12:20:45 |
| sterni | if you care about it, just add a test somewhere that comparse outPaths i'd say | 12:21:04 |
| sterni | In reply to @sternenseemann:systemli.org
emily: mainly the LLVM LLVMGold.so thing depending on GNU binutils or not, could be interesting to remove that somehow i.e. would be nice if this could be outside the LLVM derivation | 12:21:31 |
 emily | In reply to @sternenseemann:systemli.org
subtle problems are usually introduced elsewhere, so nulling it for some derivations isn't really solving anything the really nice thing about nulling it is that it allows dependency specification that people can actually make sense of https://github.com/NixOS/nixpkgs/issues/227327 | 13:35:10 |
 p14 | In reply to @sternenseemann:systemli.org
emily: mainly the LLVM LLVMGold.so thing depending on GNU binutils or not, could be interesting to remove that somehow I had noticed this one too. AFAIU, the interface it uses is stable, so shouldn’t very much in theory. I don’t know how that holds in practice. If you are building with a useLLVM tool chain with the LLD linker, then it is redundant anyway. Maybe the dependency could be dropped in that case at least? | 15:06:39 |
| sterni | I think it needs to link against libbfd (would need to verify), so it depends on whether it is available for a given target since binutils is not target agnostic | 17:10:51 |
| emily | we could just drop gold support. gold is dead. | 17:27:51 |
| emily | we don't use it by default any more IIRC and I think a lot of distributions split it out of binutils or dropped it | 17:28:06 |
| emily | (or is LLVMGold.so required for interoperating with ld.bfd too?) | 17:28:14 |
| sterni | I'm pretty sure | 17:39:09 |
| sterni | “just” for LTO though | 17:39:16 |
| sterni | Haskell uses it =^_^= | 17:39:35 |
| sterni | I wonder if it's still necessary | 17:39:54 |
| p14 | emily: sterni like this? :) https://github.com/NixOS/nixpkgs/pull/355532 | 21:52:57 |
| emily | "only" is stretching it a bit given the Darwin patch :) | 22:09:41 |
| emily | though that should be solvable | 22:09:42 |
| emily | or rather the Darwin not-patch | 22:10:06 |
 Randy Eckenrode | @emilazy:matrix.org Here is comparing the Darwin cross to a Linux cross clang: https://gist.github.com/reckenrode/9d9035cf4f070c271d2499b401078320
| 22:16:58 |
| emily | In reply to @reckenrode:matrix.org
@emilazy:matrix.org Here is comparing the Darwin cross to a Linux cross clang: https://gist.github.com/reckenrode/9d9035cf4f070c271d2499b401078320
what about on top of p14's PR? | 22:17:31 |
| emily | looks like that's the only remaining divergence | 22:17:36 |
| emily | ah, I guess it doesn't handle the patch though | 22:18:26 |
| emily | or whatever's going on there | 22:18:37 |
| Randy Eckenrode | I cherry-picked it. Still a divergence | 22:20:21 |
| Randy Eckenrode | I added it as a second file in the above gist. | 22:20:55 |
| emily | ah, because , enableGold ? withGold stdenv.targetPlatform | 22:23:03 |
| emily | p14: probably enableGoldPlugin shouldn't default to libbfd.hasPluginAPI but instead true | 22:23:19 |
| sterni | yes | 22:28:42 |
| emily | how does this even work anyway? | 22:29:34 |
| emily | do we have to point it to the right libbfd.so for the target at runtime or something? | 22:29:45 |
