| 14 Nov 2024 |
 emily | the tar thing is weird but I don't have a better idea | 16:56:44 |
| emily | it should maybe move to libbfd itself | 16:56:51 |
| emily | i.e. libbfd.plugin-api | 16:56:57 |
| emily | so that it is clear what interface we commit to there | 16:57:05 |
| emily | "-DLLVM_BINUTILS_INCDIR=${libbfd.plugin-api}/include" feels nicer | 16:57:38 |
 p14 | Seems a reasonable suggestion! I would appreciate it on-PR so I don’t forget when I come back to it.
With respect to separating LLVMgold.so into a different derivation, I am not sure of the value of that. The build system archania and subsequent potential for breakage required to do it does not seem worth the hassle. | 17:00:05 |
| emily | I don't think that was suggested, was it? | 17:00:19 |
| emily | ah, sterni did | 17:00:35 |
| emily | LLVM hates being split up. the amount of split we already have causes problems | 17:00:45 |
| emily | so I personally wouldn't prioritize that | 17:00:52 |
| emily | I will leave a review. | 17:00:55 |
| p14 | In reply to @emilazy:matrix.org
I will leave a review. Thanks for the review. I think I’ll adjust the scope of the patch by changing the title so that just the target dependence of BFD is dropped. Other fixes can come separately. | 17:35:53 |
| 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 |
