| 11 Nov 2024 |
 emily | I'm curious what nix-diff says though | 23:31:09 |
 Randy Eckenrode | Output of nix-diff $(nix-instantiate . -A clang.cc) $(nix-instantiate . -A pkgsCross.gnu64.buildPackages.clang.cc) with the NIX_DONT_SET_RPATH_FOR_TARGET change reverted and the -nostdlibinc patches dropped.
https://gist.github.com/reckenrode/be122136283d8ed5a05d52f2f57d8809
| 23:41:53 |
| emily | the bootstrap stuff seems solvable | 23:43:15 |
| emily | if we used the earlier stage compilers to bootstrap pkgsCross | 23:43:26 |
| emily | I think comparing two pkgsCrosses would be more enlightening though | 23:43:39 |
| emily | since that's still significantly more sharing | 23:43:42 |
| emily | and would eliminate that difference | 23:43:47 |
| emily | like gnu64 and aarch64-multiplatform instead | 23:43:56 |
| emily | (or I guess aarch64-multiplatform and however x86_64-darwin is spelled, to capture OS differences) | 23:45:44 |
| 12 Nov 2024 |
| Randy Eckenrode | I can check in a bit. | 00:55:17 |
 sterni | emily: mainly the LLVM LLVMGold.so thing depending on GNU binutils or not, could be interesting to remove that somehow | 12:18:23 |
| sterni | I think sharing between normal clang and cross clang is a bigger win though | 12:18:43 |
| sterni | Ideally you can just pass useLLVM and never need to rebuild anything big | 12:19:06 |
| 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 |
