| 12 Nov 2024 |
 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 |
| p14 | Sorry, headed to bed, but my understanding is that libLLVMgold is only using a well defined interface which should not vary as a function of the target. That said I am not a heavy darwin user and I am afk so can’t look there closely for now. | 22:32:08 |
| p14 | 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
I am not exactly clear on what is being diffed in these gists | 22:36:36 |
| emily | pkgsCross.gnu64.clang-unwrapped vs. pkgsCross.[I forget how you spell x86_64-darwin here].clang-unwrapped on a Darwin host, I think. | 22:36:59 |
| emily | the issue is that you still condition it on enableGold, which the LLVM derivation sets the default of to withGold stdenv.targetPlatform | 22:37:19 |
