Nixpkgs Stdenv | 230 Members | |
| 75 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Nov 2024 | ||
| how does this even work anyway? | 22:29:34 | |
do we have to point it to the right libbfd.so for the target at runtime or something? | 22:29:45 | |
| 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 | |
In reply to @reckenrode:matrix.orgI am not exactly clear on what is being diffed in these gists | 22:36:36 | |
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 | |
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 | |
so the same divergence is present. so probably that should be , enableGold ? true in LLVM. | 22:37:30 | |
| Ok. Will fix it up over the coming days. Would be helpful to know what the best expressions to test are. | 22:39:47 | |
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 | |
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 | |
| at which point Clang doesn't know what target it'll be yet AIUI | 22:41:49 | |
| so to make the patch unconditional the logic probably has to move deeper into the guts | 22:42:01 | |
| 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 | |
* 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 | |
* 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 | |
In reply to @p14:matrix.org I’m comparing | 22:44:27 | |
| If I set | 22:45:00 | |
(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 | |
* (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 | |
| https://github.com/NixOS/nixpkgs/blob/45d55abd3964711133c2c3bdfdae82e178e9ce55/pkgs/stdenv/darwin/default.nix#L1262-L1278 | 22:47:28 | |
| If clang is correctly setting itself up as a multi-target compiler, should that be overlaid unconditionally? | 22:47:45 | |
| Or at least the LLVM portion. I don’t know about the Darwin binutils stuff. | 22:48:01 | |
| That allows | 22:48:31 | |
| 13 Nov 2024 | ||
In reply to @reckenrode:matrix.orgNot clear to me. The unwrapped clang can be; but llvmPackages contains wrapped clangs which embed information about the targetPlatform, right? | 17:42:07 | |
In reply to @p14:matrix.orgAssuming the targetPlatform stuff gets dropped, so the same Clang can be used for all cross builds. | 18:11:41 | |
In reply to @reckenrode:matrix.orgSame llvmPackages.clang.cc but not same llvmPackages.clang. | 18:12:48 | |
| https://github.com/NixOS/nixpkgs/blob/45d55abd3964711133c2c3bdfdae82e178e9ce55/pkgs/stdenv/darwin/default.nix#L306_L326 | 18:13:11 | |
| * | 18:13:42 | |
| @p14:matrix.org: Just double-checked what’s overlaid. See above. Only those packages are overlaid. No wrappers are included in those packages. | 18:14:35 | |
| Ah cool. That was opaque to me, thanks for explaining! | 18:15:21 | |