| 14 Nov 2024 |
 emily | agreed | 17:36:00 |
| emily | didn't want to block the PR on it by any means | 17:36:04 |
| emily | just flagging up that there's still more to do | 17:36:11 |
 p14 | Ack. I may or may not take a closer look, since I am not a darwin user. | 17:36:37 |
| emily | FWIW, the patch applies specifically on Linux | 17:40:26 |
| emily | it's Darwin that opts out, because it breaks stuff for us | 17:40:30 |
| emily | but it's not the right thing on Linux either | 17:40:35 |
| emily | we are injecting -nostdlibinc into every command-line for dubious reasons | 17:40:41 |
| emily | of unwrapped compilers | 17:40:50 |
| 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 |
