 | Nixpkgs Stdenv | 229 Members |
| 74 Servers |
| Nixpkgs Stdenv | 229 Members |
| 74 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Nov 2024 | ||
 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.orgwhat 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.orgI 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 |
| emily | so the same divergence is present. so probably that should be , enableGold ? true in LLVM. | 22:37:30 |
| p14 | Ok. Will fix it up over the coming days. Would be helpful to know what the best expressions to test are. | 22:39:47 |
| emily | I think you want a Darwin localSystem (because of the patch conditional) and compare say {Linux, Darwin} × {x86-64, AArch64} for the target | 22:41:17 |
| emily | the -nostdinc patch will be a pain. it's a hack that we have to skip on Darwin because it doesn't help us and it breaks stuff. but it's a hack that works by patching the command-line parsing | 22:41:43 |
| emily | at which point Clang doesn't know what target it'll be yet AIUI | 22:41:49 |
| emily | so to make the patch unconditional the logic probably has to move deeper into the guts | 22:42:01 |
| emily | also, it's kind of bad on Linux too, though hard to see how to easily remove it without regressing the issue with unwrapped compilers | 22:42:16 |
| emily | * I think you want a Darwin hostPlatform (because of the patch conditional) and compare say {Linux, Darwin} × {x86-64, AArch64} for the target | 22:42:30 |
| emily | * the -nostdlibinc patch will be a pain. it's a hack that we have to skip on Darwin because it doesn't help us and it breaks stuff. but it's a hack that works by patching the command-line parsing | 22:42:43 |
| Randy Eckenrode | In reply to @p14:matrix.org I’m comparing | 22:44:27 |
| Randy Eckenrode | If I set | 22:45:00 |
| emily | (also in case it was missed, this is on a branch where Randy makes the Darwin patch check unconditional, so can't expect to reproduce those results with a Darwin hostPlatform currently) | 22:45:34 |
| emily | * (also in case it was missed, this is on a branch where Randy makes the Darwin patch check unconditional and removes the stdenv rpath stuff, so can't expect to reproduce those results with a Darwin hostPlatform currently) | 22:45:50 |