| 15 Nov 2024 |
 emily | yeah, I think there are wrapped cases | 08:54:06 |
| emily | but AIUI it was moved from the wrapper to a patch | 08:54:13 |
| emily | because of some bug report about an unwrapped compiler on non-NixOS | 08:54:20 |
 p14 | That may be, but is it clear what the route to solution is? | 08:54:21 |
| emily | which I personally do not consider compelling | 08:54:24 |
| emily | In reply to @p14:matrix.org
That may be, but is it clear what the route to solution is? re: "it also prevents clang from searching /usr/lib", it's not totally clear if this is desirable for unwrapped compilers and it can be handled in other ways in wrapped compilers | 08:55:09 |
| emily | "we should try to supply the C++ stdlib link and include flags" yes | 08:55:20 |
| emily | sysroot stuff is complicated unfortunately | 08:55:30 |
| 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 |
