| 24 Nov 2024 |
 p14 | The problem is that we put nostdlibinc into the cc-cflags, and these flags go to both the linker and the compiler, with no way in nix currently to say that a flag should only go to the compiler invocation only. | 15:21:23 |
 @paparodeo:matrix.org | I see -- clang should consume unused compiler args if it ends up being a link only step, and it seems to on clang-19, but for whatever reason it is not for clang-13 / clang-14. | 15:39:37 |
| p14 | Are you sure it's a compiler version difference and not a patched/unpatched difference? https://github.com/NixOS/nixpkgs/pull/356162/files#diff-7e3eb59be96c7378cf6880e19a4a800591680455a262eb5a5a083917ea67f8edL10 | 15:45:26 |
| p14 | The arg is claimed there. | 15:45:47 |
| p14 | I just tried with clang 13 on nixos-unstable and don't see the warning behaviour (in wrapped clang). | 15:47:20 |
| p14 | Not sure I understand why wrapping would make the warning go away | 15:47:36 |
| @paparodeo:matrix.org | I'm on staging | 15:47:40 |
| @paparodeo:matrix.org | (happened to have both built) | 15:48:16 |
| @paparodeo:matrix.org | https://github.com/llvm/llvm-project/blob/aafe934c0c0c1d274099228e7e47669770235284/clang/lib/Driver/Driver.cpp#L4131-L4137 should claim compile options for link stage. I am guessing that -nostdlibinc wasn't added to the correct group to get claimed until some change after clang-14 was released. | 15:53:03 |
| p14 | Good guess: https://github.com/llvm/llvm-project/commit/5b77e752dcd073846b89559d6c0e1a7699e58615 | 15:54:17 |
| @paparodeo:matrix.org | I have an open PR that modifies that code, so was looking at it recently. https://github.com/llvm/llvm-project/pull/116476 | 15:55:00 |
 emily | maybe we can backport that | 19:22:19 |
| @paparodeo:matrix.org | patch applies to clang [14-16] will need to be adjusted for 12 & 13 due to failing to patch hunk 2 file 1 | 21:45:55 |
| @paparodeo:matrix.org | In reply to @emilazy:matrix.org
maybe we can backport that backported with: https://github.com/NixOS/nixpkgs/pull/358836 currently building irods with patch. will mark as ready once completed. | 22:40:59 |
| emily | sometimes it feels like we're backporting half the commits in LLVM to older versions | 22:43:03 |
 Tristan Ross | In reply to @emilazy:matrix.org
sometimes it feels like we're backporting half the commits in LLVM to older versions Well now it should be easier with the common stuff. Getting patches works nicely. | 22:45:23 |
| emily | hopefully it won't be too long until we can just use new LLVMs rather than trying to make old LLVMs into them :) | 22:47:29 |
| Tristan Ross | That's what I'm hoping for | 22:50:14 |
| emily | I will probably remove some non-contiguous LLVMs when I get bored | 22:51:43 |
| @paparodeo:matrix.org | 14,16,17,18 might be easy to remove though 17-18 haven't been around for that long. | 22:54:42 |
| Tristan Ross | I would hold off removing newer LLVM versions | 22:55:57 |
| emily | I think things below 18 can go. | 22:57:14 |
| emily | (when not otherwise needed) | 22:57:20 |
| emily | since 18 has been the default and anyway Darwin has already dealt with the pain of moving off 16. | 22:57:48 |
| emily | honestly even 18 could probably go if the next staging-next goes okay. we've not had that bad a time fixing char_traits stuff | 22:59:27 |
| Tristan Ross | In reply to @emilazy:matrix.org
I think things below 18 can go. Yeah, I agree. It's just things which are relatively newer and it's probably easier to handle conflicts and removing version checks when it's older first. | 23:11:04 |
| emily | the older ones tend to be the harder ones to remove | 23:12:14 |
| emily | since stuff stuck on very old LLVMs is harder to make work on new ones | 23:12:23 |
| Tristan Ross | Hmm then we probably will have problems either way | 23:14:42 |
| emily | I don't think it's that hard to remove version checks for a specific version? | 23:16:12 |
