| 15 Nov 2024 |
 p14 | Hmm. I understand that but I actually have a usecase via elfshaker/manyclangs, which enables access to any binary of LLVM at any commit of clang with ~1s access time (and not much storage): https://github.com/elfshaker/elfshaker / https://github.com/elfshaker/manyclangs/ | 08:55:47 |
| p14 | Currently the manyclangs packs are built with Ubuntu, but I would like to build them with a static-llvm stdenv. | 08:56:11 |
 emily | but do you expect those compilers to magically know what C++ library you want to use? | 08:56:16 |
| emily | that's not how Clang works on any other distro. | 08:56:22 |
| p14 | Well, that's true, I don't especially expect that. | 08:56:33 |
| emily | ideally, we would pick no default C/C++ library so that you have to explicitly specify which to use | 08:56:37 |
| p14 | So long as it can be configured after the fact with extra flags, a config file, or a wrapper. | 08:56:44 |
| emily | right. | 08:56:49 |
| emily | and forced -nostdlibinc inhibits configuration! | 08:56:55 |
| emily | it forces a non-standard policy that makes our unwrapped Clang work unlike normal unwrapped Clang, and this is not just theoretical because it broke Darwin | 08:57:20 |
| emily | I have nothing against unwrapped compilers, just something against expecting them to adapt to stdenv-specific configuration :) | 08:58:35 |
| p14 | That all sounds fair. | 08:58:45 |
| emily | that it's hard to use the libcxxStdenv compiler because it injects libstdc++ directories, sure | 08:58:51 |
| emily | I don't think -nostdlibinc is the fix for that | 08:58:56 |
| emily | ideally we'd get the unwrapped compilers to not inject those GCC directories at all | 08:59:06 |
| emily | rather than using such a blunt tool to get there | 08:59:14 |
| emily | I forget the exact issue I found though | 08:59:29 |
| p14 |
that it's hard to use the libcxxStdenv compiler because it injects libstdc++ directories, sure
This statement reads as a surprise to me - what does 'libcxx' have to do with 'libstdc++'?
| 08:59:30 |
| emily | I think it's something like the GCC toolchain causes it to… something something | 08:59:42 |
| emily | I'll dig up the issue. | 08:59:44 |
| p14 | https://github.com/NixOS/nixpkgs/issues/151879 ? | 09:00:25 |
| emily | that might be the one for the wrapped compiler | 09:00:49 |
| emily | but maybe :) | 09:00:50 |
| emily | there's an Alyssa commit with a reproducer for the wrapped one | 09:00:57 |
| emily | hm, maybe all the reports were just for the wrapped compiler? | 09:01:08 |
| emily | but in that case I have no idea why someone felt the need to bake it into a patch | 09:01:15 |
| emily | let me do some proper digging | 09:01:22 |
| p14 | https://github.com/NixOS/nixpkgs/pull/153963 was the original patch that added it, but I did not understand the justification yet | 09:01:41 |
| emily | wow, backporting a change that incompatible to the previous release | 09:02:16 |
| p14 | No wait, looking at the patch it just changed the implementation | 09:02:19 |
