| 14 Nov 2024 |
 emily | we should kill it off for all platforms, one way or another | 17:41:05 |
| emily | In reply to @emilazy:matrix.org
FWIW, the patch applies specifically on Linux (ok, specifically on not-Darwin) | 17:41:15 |
| 15 Nov 2024 |
 p14 | In reply to @emilazy:matrix.org
we are injecting -nostdlibinc into every command-line for dubious reasons This looks like a good description of the problem: | 08:50:48 |
| p14 | https://github.com/NixOS/nixpkgs/issues/191152#issuecomment-1429029003 | 08:50:50 |
| p14 |
I think the bottom line is that we've got a matrix of toolchains and use cases we want to support (gcc or g++ or clang or clang++, libstdc++ or libc++) and a bunch of knobs we can turn (--stdlib, -nostdlibinc, --gcc-toolchain).
| 08:51:00 |
| emily | part of the motivation is AIUI for unwrapped compilers | 08:53:13 |
| emily | which I think is a busted use case (expecting a C++ library override to work with an unwrapped compiler OOTB) | 08:53:30 |
| emily | anyway, I'm pretty firmly convinced that -nostdlibinc is the wrong knob | 08:53:56 |
| p14 | Is it? I'm not sure. My read from that thread is that it breaks some wrapped cases. | 08:53:58 |
| 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 |
