Change:
{ lib, stdenv, llvm_meta <del> , monorepoSrc, runCommand </del> <ins> , monorepoSrc, runCommand, fetchpatch </ins> , cmake, ninja, python3, fixDarwinDylibNames, version , cxxabi ? if stdenv.hostPlatform.isFreeBSD then libcxxrt else libcxxabi , libcxxabi, libcxxrt, libunwind

Discussion:
Using with seems to be broken with and . It fails with . also notes this. Running yields . The contains just an empty and I am using this flake's devShell: The same also occurs when using a shell with only and when trying to use inside a nix build. I am pretty sure that this is caused by in containing instead of (which it does for ). I don't know yet, what the root cause for that is or how to fix that. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (So it shows up in the tracking issue )
Apologies for the delay in getting to this. Minimizing your example ultimately leaves me with: Staring at the output of ^ with reveals that is a linker script that appears to be passing in : For LLVM 14 this file looks like: But for LLVM 15: EDIT: whoops, my bad; just noticed that you already mentioned this in your post, I totally missed it Looking through the source, this file appears to be generated ; specifically the should be coming from based on . For Linux/macOS (i.e. platforms using libc++-abi) that should be set . Poking around a bit suggests that this is a bug in upstream; is not an interface library so it has no (though it has an ) and its is never set. And sure enough, looking at upstream reveals that has been (see ).
Applying that patch and rebuilding locally seems to fix the issue; I'll open a PR (and add regression tests for this) shortly.
Thanks for looking into this! Building from the PR-branch now no longer fails in the way I described and the example works for me again. I have now found a new issue, tho: Importing fails with: For example, this causes this error (using the same flake as above, just built from the PR branch). I was able to work around this, by adding to the end of the phase of locally, but I am not sure if that's the right approach here.
(Re I have a proposed fix for the _cxxabiconfig.h issue on llvmPackages_16: -- currently I'm inserting an additional include search dir for it.

I also don't know if this is the best approach or alternatively if that header (and friends?) should be copied into libcxx or similar.
I ran into the same missing header issue compiling using on . Maybe the fix isn't enough, and should be copied?
this change is missing from 15
running into the same problem compiling some static libraries in nixpkgs using pkgs.llvmPackages_16.libcxxStdenv. Does this warrant its own issue?
Yes, file a new issue. Please also provide reproducibility bits, including the error message you see, the package expression you're trying to build, and the nixpkgs revision. I'm guessing the issue you're seeing is failing to build, which is a different problem specific to static builds.
(If my guess is accurate, the problem you're seeing is a variant of ).
sorry for bothering you, turns out it wasn't really this issue. Using my limited knowledge on the matter from what I understand, is not installed to like . Now, turns out (and ) is a default system header path (for CXX of course) and so is BUT is not so if one were to they would just run into since that is nowhere to be found. There are two solutions to this is as a system header path like we simply just install everything under on non darwin systems as well. I actually do not know why these are all not copied on non darwin systems. Please correct me if wrong. I might be completely wrong.
check
No bother. I'm sticking my oar in because I'm interested in getting to the bottom of issues exactly like this. It's difficult to fix things it without precise reproduction steps, though. What you're describing there sounds very much like something I tried to address in (see ), which is on nixos-unstable. So it sounds like you may have found further issues, but I can't do much to help without a reproducer. In any case what you're describing sounds like a different issue to the original (which was ), so I suggest posting a new issue pretty much as you described but with a reproducer I can run at the terminal, since it is meant to be in the system include path already (per the link above). If it's not, that sounds like a bug worth filing.

Okay I found the problem, and the "obvious" solution as well, you can find it here